March/ April  2010  The  Journal  of  Defense  Software  Engineering  Vol.  23  No.  2 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 


1.  REPORT  DATE 

APR  2010 


2.  REPORT  TYPE 


3.  DATES  COVERED 

00-03-2010  to  00-04-2010 


4.  TITLE  AND  SUBTITLE 

CrossTalk.  The  Journal  of  Defense  Software  Engineering.  Volume  23, 
Number  2,  March/April  2010 

6.  AUTHOR(S) 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

517  SMXS  MXDEA,6022  Fir  Ave,Hill  AFB,UT, 84056-5820 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


5a.  CONTRACT  NUMBER 


5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 


12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 


13.  SUPPLEMENTARY  NOTES 


14.  ABSTRACT 


15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 


a.  REPORT 

unclassified 


b.  ABSTRACT 

unclassified 


c.  THIS  PAGE 

unclassified 


17.  LIMITATION  OF 

18.  NUMBER 

ABSTRACT 

OF  PAGES 

Same  as 

32 

Report  (SAR) 

19a.  NAME  OF 
RESPONSIBLE  PERSON 


Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Preparation  and  Promise 


4  Systems  Assurance  as  a  Team  Sport 

This  article  examines  several  standards  and  enumerations  that  are 
changing  the  concepts  of  assurance,  compliance,  and  security  in 
enterprises,  products,  and  practices — and  shows  how  procurement 
officers,  government  organizations,  and  software  professionals  can  bene¬ 
fit  from  them. 
by  Robert  A.  Martin 


7  A  DoD-Oriented  Introduction  to  the  NDIA’s  System 
Assurance  Guidebook 

The  National  Defense  Industrial  Association’s  “Engineering  for  System 
Assurance”  Guidebook  is  a  must-have  for  DoD  organizations  and 
contractors,  and  this  article  examines  its  benefits  in  the  areas  of 
assurance  case  claims  and  the  DoD  Management  Framework. 
by  Raul  R.  Popick,  Dr.  Terence  E.  Devine,  and  Rama  S.  Moorthy 
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Confidentiality  integrity,  and  availability  are  cornerstones  for  evaluating 
the  survivability  of  a  system,  and  die  authors  share  a  methodology  for 
assessment  as  well  as  their  first-hand  experience  with  the  most  prevalent 
forms  of  direct  attack. 
by  Michael  Atighetchi  and  Dr.  Joseph  Toy  all 


A  Look  at  “Software  Security  Engineering: 

A  Guide  for  Project  Managers” 

The  authors  show  how  to  use  software  security  practices  from  the 
recently  published  “Software  Security  Engineering:  A  Guide  for  Project 
Managers”  as  a  tool  in  selecting  practices  that  will  lead  to  more 
security-responsive  and  robust  systems. 

by  Julia  H.  Allen,  Dr.  Robert  J.  Ellison,  Dr.  Nancy  K  Mead,  Sean  Barman, 
and  Dr.  Gary  McGraw 


Building  Security  In  Using  Continuous  Integration 
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successfully  choose,  incorporate,  and  utilize  commercial  and  open  source 
Cl  tools. 

by  Thomas  Stiehm  and  Gene  Go  timer 
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From  the  Sponsor 


Reinforcing  Systems  Assurance 
In  Cyber  Risk  Management 

Systems  assurance  is  a  matter  of  strategic  concern  to  our  nation’s  security;  one  the 
DHS  takes  very  seriously.  Fundamentally,  it  is  the  concerted  effort  to  ensure  that 
users  have  the  highest  level  of  confidence  possible  in  their  critical  systems  and  data. 

In  other  words,  systems  assurance  is  the  integrated  effort  to  enhance  user  confi¬ 
dence  in  the  safety,  security,  reliability,  availability,  and  maintainability  of  processes  and 
products.  A  number  of  factors  impact  the  user  community’s  confidence,  including 
standards  setting,  procedures  development,  regulations,  and  specific  verification  and 
certification  criterion. 

Industry  and  the  government  have  been  working  hard  and  have  made  important  progress  in 
providing  systems  assurance  for  their  customers.  Collaborative  efforts  are  advancing  standards 
and  practices  for  systems  and  software  assurance. 

However,  building  and  sustaining  customer  confidence  is  difficult  and  in  an  ever-changing 
technological  environment  where  such  confidence  is  easily  diminished.  In  fact,  malicious  actors 
have  shown  great  adaptability  in  their  efforts  to  undermine  assurance  efforts.  This  is  why  we 
must  be  constantly  vigilant  and  strive  to  implement  innovative  systems  assurance  technologies. 

It  also  must  not  be  forgotten  that  enhanced  systems  assurance  supports  intellectual  proper¬ 
ty  rights  protection,  improved  consumer  trust,  and  more  confident  business  operations  and  ser¬ 
vices.  A  broad  spectrum  of  critical  applications  and  infrastructure,  from  process  control  systems 
to  commercial  applications,  depend  on  secure,  resilient  systems.  That  is  why  we  must  manage 
risks  to  these  systems  effectively  and  improve  our  capabilities  and  capacity  to  mitigate  those 
risks. 

Let  me  close  with  the  observation  that  the  most  effective  systems  assurance  efforts  are 
“baked”  into  the  risk  management  process  from  the  very  beginning  of  the  system  development 
life  cycle.  Security  and  resiliency  must  be  integrated  throughout  the  life  cycle.  If  they  are  not, 
customers  may  unknowingly  accept  risks  that  could  have  profound  financial,  legal,  and  nation¬ 
al  security  implications. 

By  working  together — building  on  efforts  already  underway,  and  striving  to  take  steps  that 
will  enhance  and  improve  confidence  in  critical  systems  and  data — we  can  make  an  impact  that 
will  better  secure  the  nation. 

I  sincerely  hope  you  enjoy  this  issue  of  CROSSTALK  and  learn  from  the  keen  insights  and 
recommendations  contained  herein. 


Gregory  Schaeffer 

Assistant  Secretary  for  Cybersecurity  and  Communications 
U.S.  Department  of  Homeland  Security 
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Systems  Assurance:  Preparation  and  Promise 


Systems  Assurance  as  a  Team  Sport 

Robert  A.  Martin 
The  MITRE  Corporation 

It  is  time  for  individual procurement  officers — and  those  who  work  with  the  vendors  and  software  developers  creating  or  deliv¬ 
ering  our  day-to-day  mission  software-based  systems — to  contribute  to,  and  accelerate  the  adoption  of  standards-based  cyber¬ 
security.  This  article  outlines  several  practical  and  straighforward  steps  that  professionals  can  take  to  speed  the  adoption  of 
the  enterprise  security  initiatives  currently  under  way,  and  to  make  those  efforts  have  a  greater  and  quicker  impact. 


Many  exciting  and  important  changes 
are  happening  within  the  market* 
place  of  cybersecurity  capabilities  and  die 
way  organizations  address  compliance, 
assurance,  and  security.  As  documented  in 
[1,  2,  3,  4],  MITRE  has  collaborated  with 
industry,  government,  and  academia 
diroughout  the  last  10  years.  They  have 
fostered  the  creation  and  adoption  of  a 
number  of  information  security  standards 
that  are  changing  the  concepts  of  compli¬ 
ance,  assurance,  and  security  in  enterpris¬ 
es,  products,  and  practices. 

While  still  evolving,  several  of  these 
standardization  efforts  have  made  their 
way  into  commercial  solutions  and  gov¬ 
ernment,  industry,  and  academic  use. 
Perhaps  the  most  visible  of  diese  have 
been  the: 

•  Common  Vulnerabilities  and  Expo¬ 
sures  (CVE)  initiative. 

•  Executive  Office  of  the  President- 
Office  of  Management  and  Budget 
(EOP-OMB)-mandated  (see  [5,  6,  7,  8, 
9])  Federal  Desktop  Core  Configura¬ 
tion  (FDCC)  effort  that  leverages  the 
Security  Content  Automation  Protocol 
(SCAP). 

•  Consensus  Audit  Guidelines  [10], 

•  Build  Security  In  (BSI)  initiative. 

CVE  is  utilized  by  the  majority  of  the 
vulnerability-related  information  provi¬ 
ders  and  tool  vendors.  The  SCAP  utilizes 
CVE  and  the  other  mature  standardiza¬ 
tion  efforts  to  clearly  define  common 
security  nomenclature  and  evaluation  cri¬ 
teria  for  vulnerability,  patch,  and  configu¬ 
ration  measurement  guidance;  it  is  intend¬ 
ed  for  adoption  by  automated  tools.  By 
specifying  and  measuring  compliance  in 
terms  of  these  standardized  concepts,  the 
community  is  moving  towards  compliant  all 
the  time  based  on  automated  measurement. 
This  method  takes  an  annual  or  tri-annual 
activity  that  had  questionable  insights 
about  the  current  security  posture  of  an 
enterprise  and  makes  it  into  a  consistent 
way  of  knowing  both  how  and  that  your 
enterprise  is  secured. 

Similar  to  the  transformation  in  opera¬ 
tional  security  measurement  (motivated  by 


the  CVE  initiative,  FDCC,  and  the  SCAP) 
are  the  changes  under  way  in  assuring  the 
resilience  and  code  security  of  the  soft¬ 
ware  making  up  the  applications  and  sys¬ 
tems  software  bought  and  built  in  organi¬ 
zations  and  government  entities.  The  BSI 
initiative  is  a  software  assurance  effort  that 
provides  practices,  tools,  guidelines,  rules, 
principles,  and  other  resources  software 
developers,  architects,  and  security  practi¬ 
tioners  can  use  to  build  security  into  soft¬ 
ware  in  every  phase  of  its  development. 
BSI  leverages  the  Common  Weakness 

“While  still  evolving, 
several  of  these 
standardization  efforts 
have  made  their 
way  into  commercial 
solutions  and 
government,  industry, 
and  academic  use.” 


Enumeration  (CWE)  and  the  Common 
Attack  Pattern  Enumeration  and 
Classification  (CAPEC)  efforts. 

To  measure  and  manage  their  cyber 
assets,  an  enterprise  will  need  to  employ 
consistent  approaches  that  are  supported 
by  automation  techniques,  typically  using 
products  from  a  variety  of  different  ven¬ 
dors.  To  make  the  finding  and  reporting  of 
issues  consistent  and  composable  across 
different  groups  of  practitioners  and 
tools,  there  has  to  be  a  set  of  standard  def¬ 
initions  of  the  things  that  are  being  exam¬ 
ined,  reported,  and  managed  [4]. 

To  reach  this  level  of  capability,  the 
standardization  has  to  make  sense  to  com¬ 
mercial  industry  so  that  it  will  be  adopted 
in  baseline  products  and  practices,  and  to 
the  academic  world  so  that  research  will 


continue  to  advance  the  state  of  the  art  in 
a  complementary  manner. 

While  there  has  been  great  progress  in 
bringing  standardization  to  some  activities 
and  tools  in  some  areas  like  the  CVE  ini¬ 
tiative,  the  SCAP/ FDCC,  and  BSI,  there  is 
still  more  that  individuals  can  do.  Those 
buying  software  products,  creating  organi¬ 
zational  policies  related  to  the  security  and 
resiliency  of  systems,  or  creating  security 
guidance  and  benchmarks  can  help  us  all 
get  to  these  greater  capabilities  faster  by 
taking  the  actions  outlined  in  this  article. 

Procurement  Guidance  for 
Purchasing  Software 

As  a  procurement  officer,  you  can  make 
sure  that  the  products  being  offered  are 
compliant  with  the  new  Federal 
Acquisition  Regulation  provision  [11], 
specifying  compliance  with  the  FDCC. 
Additionally,  procurement  officers  can 
levy  requirements  on  the  software 
providers  to: 

•  Submit  a  Common  Platform  Enu¬ 
meration  (CPE)  name  for  each  new 
release  of  the  provider’s  software. 

•  Have  a  public  address  (e-mail  and/or 
Internet)  for  the  reporting  of  security 
relevant  issues  with  the  provider’s  soft¬ 
ware. 

•  Have  a  publicly  available  statement  of 
the  time  frame  and  process  that  the 
software  provider’s  organization  fol¬ 
lows  in  addressing  reports  of  security 
relevant  issues  with  the  provider’s  soft¬ 
ware. 

•  Have  public  advisories  of  relevant 
security-related  issues  and  their  resolu¬ 
tion. 

•  Include  a  CVE  Identifier  for  security- 
related  issues  when  die  issues  are  relat¬ 
ed  to  a  software  flaw  or  default  setting 
that  constitutes  a  security  shortcoming 
in  the  provider’s  software  (as  part  of 
the  initial  public  advisory). 

•  Include  an  initial  Open  Vulnerability 
and  Assessment  Language  (OVAL) 
definition(s)  as  a  machine-readable 
description  of  how  to  tell  if  the  flaw, 
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misconfiguration,  or  incorrect  default 
settings  are  present  and  whether  any  of 
the  known  resolutions  have  been  taken 
as  part  of  the  initial  public  advisory. 

•  Include  the  base  and  initial  temporal 
severity  score  portions  of  the 
Common  Vulnerability  Scoring  System 
(CVSS)  rating  for  the  flaw  or  incorrect 
default  settings  as  part  of  the  initial 
public  advisory. 

•  Provide  advice  to  customers  on  how 
to  securely  configure  their  software 
and  do  so  utilizing  the  standards  with¬ 
in  the  SCAP.  Specifically,  offer 
extensible  Configuration  Checklist 
Description  Format  (XCCDF)  and 
OVAL  documents  representing  the 
vendor’s  recommendations  on  secure 
configuration.  Include  the  appropriate 
Common  Configuration  Enumeration 
(CCE)  identifiers  for  the  configuration 
controls  that  they  recommend  settings 
for  and  CPE  names  for  the  software 
packages  discussed. 

•  Identify  and  discuss  the  assurance 
activities  that  their  software  products 
go  through — in  terms  of  the  CWE 
names  that  are  reviewed  and  tested  for 
and  the  CAPEC  names  utilized  in  the 
analysis  and  evaluation  activities  per¬ 
formed  on  their  software. 

Government  Organizations 

As  a  government  organization  decides 
how  systems  should  be  set-up  for  opera¬ 
tional  use,  standards  can  be  used  to  con¬ 
vey  this  blessed  configuration.  This  is 
referred  to  in  [12]  as  a  SCAP-expressed 
checklist.  Specifically,  government  organi¬ 
zations  can  levy  requirements  on  their 
user  communities  to: 

•  Express  policies  and  guidelines  in  the 
XCCDF/OVAL  languages  so  that  tool 
technologies  can  use  these  machine- 
readable  descriptions  to  evaluate  the 
status  of  information  technology  with 
regards  to  those  policies  and  guide¬ 
lines. 

•  Adopt  automated  methods  utilizing 
the  machine -readable  XCCDF/OVAL 
policies  and  guidelines  for  assessing, 
reporting,  and  directing  action  on 
exceptions  to  the  policies  and  guide¬ 
lines. 

Similarly,  as  a  government  organiza¬ 
tion  establishes  its  approach  to  gaining 
assurance  about  the  robustness,  integrity, 
and  secureness  of  the  software  its  systems 
contain,  standards  can  be  used  to  clarify 
and  specify  the  types  of  evidence  and 
insights  needed  to  gain  sufficient  software 
assurance.  Specifically,  government  orga¬ 
nizations  can  require  their  user  communi¬ 
ties  to: 


•  Express  policies  and  guidelines  about 
the  assurance  of  a  capability  by  dis¬ 
cussing  the  security  weaknesses  that 
have  been  vetted  for  in  terms  of  CWE 
names  and  methods  used  to  verify  and 
test  for  security  issues  in  terms  of 
CAPEC  names. 

•  Adopt  the  use  of  automated  assess¬ 
ment  methods  that  utilize  CWE  and 
CAPEC  for  assessing,  reporting,  doc¬ 
umenting,  and  directing  action  on 
weaknesses  and  exceptions  to  the 
assurance  policies  and  guidelines.  This 
way,  issues  can  be  tracked  and  man¬ 
aged  in  a  vendor-neutral  and  consis¬ 
tent  manner. 

Procurement  Guidance 

for  Purchasing  Security  Tools 

In  general,  procurement  and  end-users 
should  request  or  require  that  the  vendors 
of  security  products  that  deal  with  securi¬ 
ty  flaws,  configuration  settings,  policies,  or 
patches  support  the  SCAP  standards.  It  is 
strongly  recommended  that  the  automat¬ 
ed  tools  used  to  implement  or  verify  secu¬ 
rity  controls  employ  SCAP  (or  similar 
standardization)  efforts  for  clearly  defined 
nomenclature  and  evaluation  criteria  not 
covered  by  the  SCAP.  Specifically,  these 
types  of  products  and  services  should: 

•  Include  the  appropriate  CVE  Identi¬ 
fier  for  security  information  that  is 
related  to  a  software  flaw  or  a  non- 
secure  default  setting. 

•  Provide  for  tire  searching  of  security- 
related  information  by  CVE  Identifier. 

•  Incorporate  the  machine-readable 
tests  for  flaws,  patches,  and  configura¬ 
tion  checks  written  in  conformance 
with  the  OVAL  Definition  Schema. 

•  Generate  machine-readable  assess¬ 
ment  results  from  tests  for  flaws, 
patches,  and  configuration  checks  in 


conformance  with  the  XCCDF  and 
OVAL  Results  Schema.  In  the  near 
future,  expect  products  to  produce 
results  in  the  Assessment  Results 
Format,  which  is  an  emerging  SCAP 
specification  that  describes  an  XML 
Schema  for  sharing  per-device  assess¬ 
ment  results  of  devices  on  IP-routed 
networks. 

•  Incorporate  the  machine-readable  re¬ 
sults  from  flaw,  patch,  and  configura¬ 
tion  check  assessments  that  are  written 
in  conformance  with  the  OVAL 
Results  Schema. 

•  Incorporate,  as  appropriate  to  the 
functionality  of  the  tool,  support  for 
the  different  severity  score  portions  of 
the  CVSS  rating  for  the  flaw  or  incor¬ 
rect  default  settings. 

An  assurance  ecosystem  has  emerged 
around  these  various  types  of  enumera- 
tive  and  language-based  standardization 
and  has  been  adopted  in  various  ways  by 
government  and  commercial  industry1;  it 
continues  to  provide  the  framework  to  the 
academic  world  for  continued  research 
and  to  industry  in  advancing  the  state  of 
the  art  in  a  complementary,  interoperable 
manner. 

While  there  has  been  great  progress  in 
bringing  standardization  to  many  prac¬ 
tices  and  tools,  there  is  more  that  individ¬ 
uals  can  do  to  push  even  greater  capabili¬ 
ties  to  emerge  in  a  timely  manner. 
Procurement  officials  and  consumers  of 
software  products,  as  well  as  organization¬ 
al  security  policy  makers,  should  take 
more  deliberate  action  to  demand  secure 
products  and  create  security  guidance  and 
benchmarks,  in  turn  helping  to  get  to 
these  greater  capabilities  faster;  [12] 
addresses  many  aspects  of  this  issue. 
Similar  adoption  endorsement  initiatives 
and  efforts — to  move  forward  and  sup¬ 
port  other  useful  standards  initiatives — 


Table  1:  Emerging  Standardisation  Efforts 


Activity 

Focus 

Web  site 

Assessment  Results  Format 

Result  Reporting 

<http://msm.mitre.org/incubator> 

Common  Event  Expressions 

Security  Events 

<http://cee.mitre.org> 

Policy  Language  for  Assessment 
Results  Reporting 

Result  Reporting 

<http://msm.mitre.org/incubator/plarr> 

Malware  Attribute  Enumeration 
and  Characterization 

Malware  Attributes 

<https://buildsecurityin.us-cert.gov/ 

swa/malact.html> 

Common  Remediation 

Enumeration 

Remediation  Actions 

<http://msm.mitre.org/incubator> 

Common  Remediation  Language 

Remediation  Actions 

<http://msm.mitre.org/incubator> 

Open  Checklist  Interactive 
Language 

Interactive  Survey  Questions 

<http://scap.nist.gov/specifications/ocil> 

Open  Checklist  Reporting 
Language 

Interactive  Survey  Answers 

<http://ocrl.mitre.org> 
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Software  Defense  Application 

The  rollout  of  efforts  like  SCAP-enabled  operational  measurement  is  setting  die 
stage  for  higher  levels  of  assurance  in  cybersecurity,  but  it  must  be  balanced  with  sim¬ 
ilar  levels  of  assurance  in  the  software  products  themselves.  Additionally,  all  of  die 
other  commercial  and  open  source  applications  and  capabilities  fielded  in  the  DoD 
must  participate  in  these  efforts.  This  article  describes  how  the  federal  government 
and  the  commercial  industries  working  our  nation’s  critical  industries  and  infrastruc¬ 
ture  can — by  embracing  and  accelerating  die  adoption  of  these  standards  efforts  into 
all  the  procurement  and  development  efforts  in  defense — make  the  promises  of 
greater  assurance  and  resiliency  happen  faster  and  more  completely. 


will  be  important  in  creating  needed 
changes  to  their  operational  use  and  in 
bringing  discipline  and  repeatability  into 
security  measurement  [13,  14]. 

While  already  making  many  useful  and 
needed  changes  possible,  these  common 
enumerations  and  languages  will  continue 
to  evolve  and  grow  to  cover  additional 
areas  of  standardization.  Some  of  the 
emerging  areas  already  being  worked  as 
standardization  efforts  are  for  security 
events,  malware  attributes,  attack  patterns 
as  operational  model  templates,  remedia¬ 
tion  actions,  and  interactive  survey  ques¬ 
tions  and  result  reporting  (as  shown  in 
Table  1,  previous  page). 

These  new  standardization  areas  (like 
those  outlined  in  dais  article)  have  the 
potential  to  evolve  into  similarly  beneficial 
standards  efforts  for  those  working  to 
secure  their  enterprises.  The  key  to  realiz¬ 
ing  the  promise  of  these  new  efforts  are 
die  communities  working  on  them  and  the 
inclusiveness  and  fair-handedness  of  the 
process  surrounding  these  efforts.  The 
growth  and  maturity  of  these  new  areas 
should  be  monitored  and  evaluated 
against  today’s  threats  and  operational 
challenges.  This  way,  organizations  can 
leverage  the  ideas  and  processes  as  soon  as 
possible  and  anyone  with  insights  and 
interests  in  these  areas  can  get  involved. ♦ 
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Despite  significant  strides  toward  building  secure  and  trustworthy  systems,  there  is  ample  evidence  that  adversaries  retain 
their  ability  to  compromise  systems.  ‘Engineering  for  System  Assurance  ”  [1]  (the  Guidebook) — a  publication  from  the 
National  Defense  Industrial  Association  (NDIA) — provides  process  and  technology  guidance  to  increase  the  level  of  sys¬ 
tems  assurance  (SA).  One  section  has  guidance  particularly  useful  to  the  DoD  and  their  contractors.  This  article  provides 
an  introduction  to  key  SA  activities  with  an  emphasis  on  the  selected  reviews  within  the  DoD  Eife-Cycle  Management 
Framework. 


For  decades,  industry  and  defense  orga¬ 
nizations  have  tried  to  build  afford¬ 
able,  secure,  and  trustworthy  systems. 
Despite  significant  strides  toward  this 
goal,  there  is  ample  evidence  showing  that 
adversaries  retain  their  ability  to  compro¬ 
mise  systems.  Consequently,  there  is  grow¬ 
ing  awareness  that  systems  must  be 
designed,  built,  and  operated  with  the 
expectation  that  system  elements  will  have 
both  known  and  unknown  vulnerabilities. 
SA  is  defined  as: 

The  justified  confidence  that  the 
system  functions  as  intended  and  is 
free  of  exploitable  vulnerabilities, 
either  intentionally  or  unintention¬ 
ally  designed  or  inserted  as  part  of 
die  system  at  any  time  during  the 
life  cycle.  [1] 

This  ideal  of  no  exploitable  vulnerabilities 
is  usually  unachievable  in  practice,  so  pro¬ 
grams  must  perform  risk  management  to 
reduce  (to  acceptable  levels)  the  probabil¬ 
ity  and  impact  of  vulnerabilities. 

This  confidence  is  achieved  by  SA 
activities,  which  include  a  planned,  sys¬ 
tematic  set  of  multi-disciplinary  activities 
to  achieve  the  acceptable  measures  of  SA 
and  manage  the  risk  of  exploitable  vulner¬ 
abilities.  The  assurance  case  is  the  enabling 
mechanism  showing  that  the  system  will 
meet  its  prioritized  requirements  and  that 
it  will  work  as  intended  in  the  operational 
environment,  minimizing  the  risk  of 
exploitation  through  weaknesses  and  vul¬ 
nerabilities. 

The  Guidebook  is  intended  primarily 
to  aid  program  managers  and  systems 
engineers  seeking  guidance  on  how  to 
incorporate  assurance  measures  into  dieir 
system  life  cycles.  Assurance  for  security 
must  be  integrated  into  the  systems  engi¬ 
neering  activities  to  be  cost-effective, 
timely,  and  consistent.  The  activities  for 
developing  and  maintaining  the  assurance 


case  enable  rational  decision-making  so 
that  only  the  actions  necessary  to  provide 
adequate  justification  (arguments  and  evi¬ 
dence)  are  performed.  The  Guidebook  is 
a  synthesis  of  knowledge  gained  from 
existing  practices,  recommendations,  poli¬ 
cies,  and  mandates.  SA  activities  are  exe¬ 
cuted  throughout  die  system  life  cycle.  It 
is  organized  based  on  the  ISO/IEC’s 

programs  must 
perform  risk 
management  to  reduce 
(to  acceptable  levels) 
the  probability  and 
impact  of 
vulnerabilities. ,f 

“Systems  and  Software  Engineering  - 
System  Life  Cycle  Processes”  [2];  while 
diere  are  other  life-cycle  frameworks,  this 
standard  combines  a  suitably  encompass¬ 
ing  nature  while  also  providing  sufficient 
specifics  to  drive  SA. 

This  Guidebook  also  provides  an 
assurance  guidance  section  for  use  by  the 
DoD  and  their  contractors  and  subcon¬ 
tractors.  Future  editions  of  this 
Guidebook  may  add  additional  domain- 
specific  assurance  guidance. 

This  article  provides  an  overview  of 
die  assurance  case  section  (Section  2.2) 
and  then  describes  key  SA  activities  com¬ 
pleted  for  selected  reviews  within  the 
DoD  Integrated  Defense  Acquisition, 
Technology,  and  Logistics  Life-Cycle 
Management  Framework  (referred  to  in 
this  article  simply  as  the  DoD 
Management  Framework)  from  Section  4 
of  the  Guidebook. 


Assurance  Case1 

The  purpose  of  an  assurance  case  is  to 
provide  a  convincing  justification  to  stake¬ 
holders  diat  critical  SA  requirements  are 
met  in  the  system’s  expected  environ¬ 
ment^).  Any  assurance  claims  about  the 
system  need  to  be  incorporated  into  the 
system  requirements. 

An  assurance  case  is  the  set  of  claims 
of  critical  SA  properties,  arguments  that 
justify  the  claims  (including  assumptions 
and  context),  and  evidence  supporting  the 
arguments.  The  development  of  the  assur¬ 
ance  case  results  in  SA  requirements  that 
are  then  flowed  to  the  system  architecture 
and  die  product  baseline.  The  assurance 
case  can  be  considered  an  extension  or 
adaptation  of  the  safety  case,  which  has 
been  used  for  safety-critical  systems.  Thus, 
the  concept  is  not  entirely  new. 

The  assurance  case  need  not  be  a  sep¬ 
arate  document;  it  may  be  distributed 
among  or  embedded  in  existing  docu¬ 
ments.  Even  if  there  is  an  assurance  case 
document,  it  would  typically  contain  many 
references  to  other  documents.  Regardless 
of  how  the  assurance  case  is  documented, 
there  must  be  a  way  to  identify  all  of  the 
assurance  claims,  and  from  those  claims 
trace  through  to  their  supporting  argu¬ 
ments,  and  from  those  arguments  to  the 
supporting  evidence.  For  example,  an 
organization  might  maintain  a  list  of  sys¬ 
tem  requirements,  tagging  specific  ones  as 
assurance  claims  with  hyperlinks  to  argu¬ 
ments  that  justify  why  the  system  will 
meet  the  claim.  As  a  minimum: 

1 .  Assurance  case  claims,  arguments,  and 
evidence  must  be  relevant  for  die  sys¬ 
tem  and  its  operating  environment(s). 

2.  Claims  are  justified  by  their  arguments. 

3.  Arguments  are  supported  by  dieir  evi¬ 
dence. 

4.  The  assurance  case  must  be  developed 
iteratively,  be  sustainable,  and  be  main¬ 
tained  throughout  the  system  life  cycle 
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Figure  1:  Life-Cycle  Phases  with  Reviews  from  the  2003  I  'ersion  of  DoD  Instruction  5000.2) 


as  a  living  document. 

5.  The  assurance  case  must  be  delivered 
as  part  of  the  system,  to  be  maintained 
during  system  sustainment. 

The  Guidebook  makes  no  attempt  to 
specify  a  format  for  an  assurance  case, 
only  providing  guidance  as  to  what  infor¬ 
mation  should  be  included.  The  current 
revision  of  ISO/IEC  15026  [3]  specifies  a 


standard  for  assurance  cases. 

The  assurance  case  is  generated  by  the 
systems  engineering  technical  activities 
applied  to  the  assurance  requirements,  and 
provides  evidence  of  the  growing  techni¬ 
cal  maturity  of  the  integration  of  the  SA 
requirements  for  use  within  event-driven 
technical  management.  Sections  3  (gener¬ 
al)  and  4  (DoD-specific)  of  the  Guide¬ 


book  relate  tire  assurance  case  to  the  life- 
cycle  processes. 

The  DoD  Management 
Framework 

Section  4  is  for  use  by  the  DoD  and  DoD 
contractors  and  subcontractors.  It  is  orga¬ 
nized  according  to  phases  of  the  DoD 
Management  Framework  discussed  in 
DoD  Directive  5000.1  [4],  DoD 

Instruction  5000.2  [5]2,  and  the  Defense 
Acquisition  Guidebook  (DAG)  system  life 
cycle  [6]. 

Section  4’s  goal  is  to  enable  the  DoD 
to  acquire  or  produce  assured  systems, 
including  both  weapons  systems  and  IT 
systems.  This  section  discusses  the  topics 
that  should  be  addressed  during  the  phas¬ 
es  of  the  DoD  Management  Framework. 
As  discussed  in  [5]  and  [6],  the  life-cycle 
phases  include: 

•  Concept  Refinement. 

•  Technology  Development. 

•  System  Development  and  Demonstra¬ 
tion. 

•  Production  and  Deployment. 

•  Operations  and  Support. 

Section  4.3  is  subdivided  into  DoD 
review  milestones  and  milestone  decision 
points  in  this  framework.  For  each  review 
(including  the  System  Engineering 
Technical  Reviews),  the  DAG  description 
is  quoted,  followed  by  a  list  of  the  most 
important  SA  items  to  complete  prior  to 
that  milestone.  The  non-SA  activities  nor¬ 
mally  associated  with  the  review  are  not 
specified,  but  should  be  considered  as  the 
context  in  which  the  SA  activities  are  per¬ 
formed.  For  each  review,  a  specific  cross- 
reference  to  the  corresponding  general 
technical  instruction  is  also  provided. 
Where  there  are  assurance  activities  that 
cannot  be  associated  with  specific  reviews, 
additional  subsections  are  added  to  con¬ 
tain  them. 

Figure  1  depicts  the  DoD  life-cycle 
phases.  The  reviews  that  are  discussed  in 
this  article  are  shown  in  their  phases  to 
provide  a  visualization  of  when  the  review 
occurs.  Note  that  the  reviews  shown  are  a 
subset  of  life-cycle  reviews. 

Section  4  focuses  on  the  DoD  and 
makes  the  assumption  that  the  audience 
includes  system  integrators  providing  sys¬ 
tems  (both  IT  and  warfighting)  to  the 


Figure  2:  ASR  Excerpt 

To  successfully  complete  the  ASR  review,  ensure  the  following  SA  items  were  satis¬ 
factorily  completed: 

•  System  threats  and  SA  claims  were  considered  as  part  of  the  analysis  of  alterna¬ 
tives  and  full  system  life-cycle  costs  were  used  in  the  analysis.  Sometimes  the 
seemingly  cheapest  alternative  has  higher  system  life-cycle  costs  due  to  assurance 
complications. 

•  A  preliminary  identification  of  critical  technologies  with  a  description  of  how  to 
assure  these  technologies.  This  list  will  eventually  feed  the  Critical  Program 
Information  (CPI)  developed  at  the  start  of  the  System  Development  and 
Demonstration  phase.  As  an  aid  to  this  identification,  review  the  Military  Critical 
Technologies  List  (http://www.dtic.mil/mctl/). 

•  The  Initial  Capabilities  Document  (ICD)  and  Preliminary  System  Specification 
includes: 

0  The  requirement  for  the  development  of  an  assurance  case  with  high-level 
claims  for  each  system  element  determined  to  be  critical. 

0  The  sustaining  mission  operational  requirements  constrain  the  top-level  SA 
claims  to  counter  identified  threats  to  the  mission.  They  should  broadly  iden¬ 
tify  an  approach  for  developing  the  system  assurance  case. 

0  A  critical  elements  list. 

0  The  Support  and  Maintenance  Concepts  and  Technologies  with  a  description 
of  how  assurance  will  be  maintained. 


Figure  3:  ARR  Excerpt 

To  successfully  complete  the  SRR,  ensure  that  the  following  SA  items  were  satisfac¬ 
torily  completed: 

•  ICD  and  Preliminary  System  Performance  Specification: 

0  Establishes  the  requirement  for  the  development  of  an  assurance  case,  includ¬ 
ing  high-level  claims  for  a  system  determined  to  be  critical. 

0  The  operational  requirements  necessary  to  sustain  the  mission  include  the 
top-level  SA  claims  that  address  identified  threats  to  the  mission  that  are  the 
foundation  for  the  assurance  case.  Critical  elements  are  identified. 

0  The  Support  and  Maintenance  Concepts  and  Technologies  documented  with 
a  description  of  how  assurance  will  be  maintained. 

0  Requirements  with  SA  implication  have  been  tagged  for  SA  traceability  and 
verification. 

•  Identification  of  all  critical  elements  to  be  protected,  and  what  aspects  of  them 
are  to  be  protected  (e.g.,  confidentiality,  integrity,  availability,  authentication, 
accountability  [including  non-repudiation],  and  auditability).  For  example,  ensure 
that  an  adversary  cannot  gain  control  over  a  weapon  system. 

0  Initial  identification  of  potential  CPI,  and  a  preliminary  approach  to  the  pro¬ 
tection  of  that  CPI  is  part  of  the  system  requirements. 

0  Identification  of  all  relevant  SA  threats  and  their  potential  impact  on  critical 
system  assets. 
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DoD  environment. 

The  following  subsections  provide  a 
description  of  selected  key  activities  for  a 
subset  of  die  reviews  and  events. 

Alternative  Systems  Review  (ASR) 

The  ASR  occurs  during  the  Concept 
Refinement  Phase  prior  to  Milestone  A. 
Figure  2  shows  a  partial  excerpt  of  tire  list 
of  the  SA  activities  to  be  completed  prior 
to  the  ASR. 

At  this  point  in  the  life  cycle,  a  key  SA 
activity  for  each  alternative  is  shown  in  the 
first  bullet  of  Figure  2.  For  each  alterna¬ 
tive,  a  threat  analysis  and  die  assurance 
case  claims  (to  counter  the  identified 
drreats)  need  to  be  developed.  This  analy¬ 
sis  needs  to  be  factored  into  the  alterna¬ 
tive  cost  estimates,  die  selection  of  a  pre¬ 
ferred  system  concept,  and  the  technology 
development  strategy.  SA  is  made  more 
complex  when  it  is  not  considered  in  the 
early  stages  when  alternative  concepts  are 
being  evaluated. 

Systems  Requirements  Review  (SRR) 

The  SRR  can  occur  at  die  end  of  the 
Technology  Development  Phase  prior  to 
Milestone  B,  at  the  start  of  the  System 
Development  and  Demonstration  Phase, 
or  both.  Figure  3  shows  a  small  excerpt  of 
die  list  of  the  SA  activities  to  be  complet¬ 
ed  prior  to  the  SRR. 

Development  of  die  assurance  case 
claims  assists  with  die  development  of  the 
system  requirements  for  assurance.  Using 
an  assurance  case  that  systematically 
examines  die  claims  necessary  to  counter 
die  threats  will  produce  a  set  of  derived 
security  requirements  that  can  be  added  to 
die  system  requirements.  Flaving  a  robust 
set  of  security  requirements  by  SRR 
allows  die  security  to  be  built  into  the  sys¬ 
tem  rather  than  tacked  on  during  the  test¬ 
ing  or  production  phase. 

Preliminary  Design  Review  (PDR) 

The  PDR  occurs  during  the  System 
Development  and  Demonstration  Phase, 
after  Milestone  B3.  Figure  4  shows  an 
excerpt  from  the  list  of  the  SA  activities  to 
be  completed  prior  to  the  PDR. 

The  first  bullet  of  Figure  4  lists  the 
identification  of  critical  components  and 
examination  of  those  components  for 
weaknesses  and  vulnerabilities.  Critical 
components  may  be  managed  through 
techniques  such  as  graceful  degradation, 
isolation,  modularity,  diversity,  single- 
point-of- failure  reduction/multipathing, 
and  die  use  of  interchange  standards  to 
reduce  die  number,  size,  and  impact  of 
critical  elements.  Many  of  these  approach¬ 
es  become  cost-prohibitive  if  the  weak- 


To  successfully  complete  the  PDR,  ensure  the  following  SA  items  were  satisfactorily 
completed: 

•  Use  die  architecture  and  preliminary  design  information  (as  available)  to  identify 
critical  components.  Identify  weaknesses  and  their  associated  potential  vulnera¬ 
bilities.  Note  that  a  weak  architecture  can  result  in  a  systemic  weakness,  which  can 
in  turn  lead  to  many  vulnerabilities.  Thus,  a  rigorous  review  of  the  architecture 
may  be  required  prior  to  release  to  design  phase.  Refine  and  document  a  baseline 
of  attack  scenarios  of  the  identified  threats  and  assets  (see  Information 
Assurance  [IA]  control:  VIVM-1). 

•  Development  of  specific  instances  of  SA  scenarios,  at  least  for  the  critical  SA 
requirements,  to  verify  that  die  system  will  counter  the  attack. 

•  Architecture  and  preliminary  system  design  includes  IA  accreditation  require¬ 
ments  in  its  relationship  to  all  hosting  enclaves  and  impact  analysis  is  completed 
for  the  architecture.  Develop  a  list  of  all  hosting  enclaves  as  a  baseline  for  track¬ 
ing  purposes  as  the  system  moves  into  die  detailed  design  phase  (see  IA  controls: 
DCII-1,  DCID-1). 

0  Ensure  that  the  architecture  and  preliminary  system  design  of  mobile  code 
usage  is  evaluated  for  acceptable  risk,  avoiding  high  risk  as  defined  by  DoD 
requirements  (see  IA  control:  DCMC-1  [Mobile  Code]). 

0  Exclude  binary  or  machine  executable  public  domain  software  products  with 
no  warranty  and  no  source  code  (see  IA  control:  DCPD-1). 

Figure  4:  PDR  Excerpt 

ness  and  vulnerability  analysis  is  delayed 
until  late-stage  testing  and  production. 

These  activities  tie  into  IA  through  its 
control  for  vulnerability  management, 
known  as  VIVM-1 . 

Critical  Design  Review  (CDR) 

The  CDR  occurs  during  the  System 
Development  and  Demonstration  Phase. 

Figure  5  shows  an  excerpt  from  the  list  of 
die  SA  activities  to  be  completed  prior  to 
die  CDR. 

Figure  5:  CD R  Excerpt 

To  successfully  complete  the  CDR  review,  ensure  the  following  SA  items  were  satis¬ 
factorily  completed: 

•  Update  die  system  requirements,  the  functional  baselines,  and  the  allocated  base¬ 
line  to  incorporate  the  claims,  arguments,  and  scenarios. 

•  Capture  assurance  designs  in  the  associated  configuration  item  build-to  docu¬ 
mentation  as  part  of  the  system’s  Product  Baseline.  The  system’s  configuration 
item  verification  planning  should  be  updated  and  included  in  the  Product 
Baseline. 

•  Update  the  SA  case  based  on  the  design,  new  weaknesses,  vulnerabilities  identi¬ 
fied,  and  the  preceding  analysis. 

0  For  each  SA  claim,  define  the  detailed  argument(s)  to  be  used  to  justify  the 
claim,  identify  die  expected  evidence  (type  and  expected  measure)  that  will 
support  the  argument,  and  how  diat  evidence  will  be  acquired  (including  what 
verification  data  must  be  created  to  acquire  that  evidence). 

0  After  CDR,  the  assurance  case’s  claims  and  argument  structure  are  baselined, 
some  evidence  is  already  available,  and  the  methods  for  acquiring  the  remain¬ 
ing  evidence  have  been  defined. 

•  Define  and  select  assurance-specific  static  analysis  and  assurance-specific  criteria 
to  be  examined  during  peer  reviews,  to  be  performed  during  implementation. 

0  Plan  for  training  for  assurance-unique  static  analysis  tools  and  peer  reviews. 

0  Ensure  that  another  party  (such  as  a  peer)  will  independently  perform  static 
analysis  and  test,  and  that  die  element  being  reviewed  will  be  the  element  that 
will  be  delivered.  This  counteracts  the  risk  of  a  developer  intentionally  sub¬ 
verting  analysis  and  test,  as  well  as  aiding  against  unintentional  errors. 


The  first  bullet  in  Figure  5  indicates 
that  prior  to  the  CDR  the  system  require¬ 
ments,  the  functional  baseline,  and  the 
allocated  baseline  need  to  be  updated  to 
incorporate  the  claims,  arguments,  scenar¬ 
ios,  and  any  design  changes  as  a  result  of 
the  assurance  case  analysis.  The  fourth 
main  bullet  indicates  the  need  to  define 
and  select  assurance-specific  static  analysis 
and  criteria  for  examination  during  peer 
reviews  (performed  during  implementa¬ 
tion).  These  are  key  activities  needed  to 


March/ April  2010 


www.stsc.hill.af.mil  9 


Systems  Assurance:  Preparation  and  Promise 


cutable  public  domain  software  prod¬ 
ucts  with  no  warranty  and  no  source 
code. 

Production  Readiness  Review  (PRR) 

The  PRR  examines  whether  the  system  is 
ready  for  production.  From  an  SA  stand¬ 
point,  the  test  results  are  examined  to 
ensure  that  all  of  the  system  require¬ 
ments  have  been  met.  This  entails  look¬ 
ing  at  test  results  that  substantiate  the 
claims  in  the  assurance  case.  Figure  6 
shows  an  excerpt  from  the  list  of  the  SA 
activities  to  be  completed  prior  to  the 
PRR. 

The  first  bullet  discusses  the  need  to 
incorporate  test  results  for  weaknesses 
into  the  assurance  case  as  evidence.  The 
weaknesses  and  vulnerabilities  need  to  be 
baselined  and  documented  appropriately 
in  accordance  with  die  applicable  IA  con¬ 
trol.  The  extent  to  which  SA  work  was 
performed  during  the  early  stages  is 
apparent  during  die  verification  of  the  test 
results  tied  to  each  of  die  requirements; 
early  emphasis  greatly  simplifies  the  verifi¬ 
cation. 

Conclusion 

The  Guidebook  is  intended  to  help  allevi- 
ensure  the  software  being  developed.  Also  •  Developing  a  list  of  hosting  enclaves.  ate  problems  by  increasing  awareness  of 

at  diis  point,  the  design  must  meet  IA  •  Evaluating  mobile  code  usage.  SA  issues,  encouraging  these  issues  to  be 

accreditation  requirements,  including:  •  Excluding  binary  and  machine-exe-  addressed  early  in  the  development  life 


To  successfully  complete  the  PRR  review,  ensure  the  following  SA  items  were  satis¬ 
factorily  completed: 

•  Incorporation  of  the  results  of  system  test  for  weaknesses  and  dieir  associated 
vulnerabilities  into  the  assurance  case.  Verification  that  the  system  weaknesses 
and  vulnerabilities  have  been  baselined  and  appropriately  documented  (see  IA 
control:  VIVM-1). 

•  Verification  that  die  developed  system  uses  comprehensive  test  procedures  to  test 
any  and  all  patches  and  upgrades  required  throughout  its  life  cycle  (see  IA  con¬ 
trol:  DCCT-1). 

•  Incorporation  of  the  results  of  any  testing,  using  industry  tools  and  test  cases,  for 
any  binary  or  machine-executable  public  domain  software  products  with  no  war¬ 
ranty  and  no  source  code  being  used  in  the  system  (see  IA  control:  DCPD-1). 

•  Evaluation  of  the  relevant  test  results  to  obtain  the  evidence  required  to  build  die 
assurance  case  from  the  following  list  of  defensive  functions  of  a  system  as  well 
as  assurance  mechanisms  diat  address  security,  partitioning,  access,  and  traceabil¬ 
ity  mechanisms: 

0  Evaluation  of  the  protection  mechanisms  with  each  external  interface  and 
associated  security  requirements  using  test  results  as  well  as  other  evidence 
(see  IA  control:  DCFA-1). 

0  Evaluation  of  die  adequacy  of  security  best  practices  of  such  functions  as 
identification/authentication  (individual  and  group)  using  DoD  PKI,  logon 
including  single  sign-on,  PKE,  key  management,  smart  card,  and  biometrics 
(see  IA  controls:  as  per  DoDI  8500.2,  DCBP-1,  IATS-2,  IAAC-1,  IAGA-1, 
IAIA-2,  IAKM-3,  ECLO-2,  ECPA-1). 

0  Reverification  that  user  interface  services  are  logically  or  physically  separated 
from  data  storage  and  management  services.  This  is  particularly  important  in 
high  assurance  systems  (see  IA  control:  DCPA-1). 

Figure  6:  PRR  Excerpt 
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cycle,  and  providing  pointers  to  available 
resources.  The  Guidebook  shows  how  SA 
can  be  implemented  in  die  existing  envi¬ 
ronment  and  life  cycle.  It  does  not  repre¬ 
sent  original  research,  but  rather  a  survey 
of  existing  work. 

The  plan  is  to  update  the  Guidebook 
to  reflect  and  incorporate  feedback 
received  from  the  programs  that  use  it, 
December  2008  changes  to  [5],  and  new 
techniques  as  diey  emerge.  The  expecta¬ 
tion  is  that  this  article  will  encourage  pro¬ 
grams  to  use  the  Guidebook  and  to 
address  SA  issues  early  in  the  life  cycled 
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Meaningful  and  Flexible  Survivability  Assessments: 

Approach  and  Practice® 


Michael  Atighetchi  and  Dr.  Joseph  Loyall 
Raytheon  BBN  Technologies 

With  the  increase  of  IT  assets  and  attacks  against  them — along  with  increased  attention  to,  and  concern  for,  cybersecurity 
and  the  survivability  of  systems — systems  assurance  assessment  has  become  more  important  than  ever.  This  article  describes 
a  flexible  process  for  assessing  systems  with  respect  to  security  and  survivability.  We  discuss  how  our  approach  enables  assess¬ 
ments  throughout  the  project  life  cycle  by  tailoring  the  testing  to  a  specific  evaluation  scope  in  terms  of  depth  and  coverage. 


Current  systems  assurance  testing  tends 
to  focus  on  functional  and  perfor¬ 
mance  testing  and  often  postpones  securi¬ 
ty  assessments  until  the  end  of  the  project 
life  cycle — or  after  deployment  or  release. 
In  our  view,  this  shortcoming  can  be  par¬ 
tially  explained  by  the  large  cost  and  tech¬ 
nical  difficulty  of  formal  security  testing 
(e.g.,  during  certification  and  accredita¬ 
tion),  and  the  lack  of  standardized  non¬ 
binary  security  metrics.  For  example,  the 
testing  guide  of  the  Open  Web 
Application  Security  Project  (OWASP)  [1] 
contains  more  than  340  pages  on  good 
security  testing  procedures  but  provides 
little  guidance  in  selecting  which  tests  to 
perform  for  a  given  application. 

In  this  article,  we  present  a  flexible 
process  for  assessing  evolving  prototype 
systems  with  respect  to  security  and  sur¬ 
vivability.  Also  discussed  is  how  our 
approach  enables  assessments  of  confi¬ 


dentiality,  integrity,  and  availability  (CIA,  a 
concept  detailed  in  the  sidebar)  through¬ 
out  the  project  life  cycle  by  tailoring  the 
testing  to  a  specific  evaluation  scope  in 
terms  of  depth  and  coverage.  This 
process  has  enabled  us  to  conduct  securi¬ 
ty  evaluations  early  in  project  life  cycles 
and  focus  architecture  and  design  efforts 
on  addressing  the  shortcomings  identified 
through  repeated  tests. 

To  show  the  testing  methodology  in 
action,  this  article  provides  details  on  a  set 
of  specific  open-source  and  freely  avail¬ 
able  tools  we  have  found  useful  in  our 
evaluations.  The  focus  of  this  article  is  not 
on  comparing  different  tools  and  their 
capabilities,  but  rather  on  showing, 
through  insight  from  our  test  attacks ,  what 
vulnerabilities  can  be  identified  and  how 
these  tools  can  be  reused  across  evalua¬ 
tions  of  different  systems. 

Finally,  we  report  on  the  most  recent 


assessment  of  an  information  manage¬ 
ment  system  (IMS),  implementing  a  pub¬ 
lish,  subscribe,  and  query  (PSQ)  capability. 

After  giving  a  brief  testing  methodolo¬ 
gy  overview,  this  article  will  detail  static 
code  analysis  and  memory  profiling  tools 
used  in  capturing  a  broad  set  of  coding 
mistakes,  present  significant  hands-on 
technical  knowledge  that  can  be  used  to 
study  risk  exposure  CIA  loss,  and  propose 
the  next  steps  in  both  improving  surviv¬ 
ability  assessments  and  mitigating  vulnera¬ 
bilities. 

Survivability  Assessment 
Methodology 

Continuous  test  and  evaluation  of  securi¬ 
ty  attributes  of  systems  is  an  important 
part  of  testing  as  it  allows  software  devel¬ 
opers  to  identify  and  address  vulnerabili¬ 
ties  as  part  of  the  system  architecture  and 
design.  This  article  describes  a  repeatable 
survivability  testing  methodology  that 
optimizes  the  set  of  tests  to  execute  given 
limited  budget  constraints  and  can  run  as 
part  of  continuous  build  processes.  Figure 
1  displays  the  main  threads  of  our  testing 
methodology  as  boxes. 

First,  we  utilized  existing  tools  for  stat¬ 
ic  code  analysis  and  memory  profiling.  These 
tools  provide  excellent  coverage  at  mini¬ 
mal  cost  but  only  support  validation 
against  a  set  of  specialized  known  prob¬ 
lems.  Next,  we  performed  a  series  of 
stress  tests  that  simulated  conditions 
found  in  operational  environments,  which 
tend  to  be  less  controllable  than  lab  envi¬ 
ronments.  Tests  in  this  category  focused 
on  studying  the  impact  of  a  large  number 
of  clients  and  large  size  information 
objects  on  critical  server  functionality. 
These  tests  were  narrower  in  scope  than 
static  code  checks  and  memory  profiling, 
symbolized  by  the  “Stress  Testing”  box  in 
Figure  1.  Finally,  we  developed  a  set  of 
direct  attacks  against  the  system  with  dif¬ 
ferent  attacker  privileges,  ranging  from 
attacks  launched  with  only  network  layer 
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Figure  1 :  The  Survivability  Evaluation  Process 
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The  CIA  Triad 

Confidentiality  (C)  is  the  assurance  that  information  is  not  disclosed  to  unau¬ 
thorized  individuals,  programs,  or  processes.  For  example,  a  credit  card  transaction 
on  the  Internet  requires  the  credit  card  number  to  be  transmitted  from  the  buyer 
to  the  merchant  and  from  the  merchant  to  a  transaction  processing  network.  The 
system  attempts  to  enforce  confidentiality  by  encrypting  the  card  number  during 
transmission,  by  limiting  the  places  where  it  might  appear  (e.g.,  in  databases,  back¬ 
ups,  or  printed  receipts),  and  by  restricting  access  to  the  places  where  it  is  stored. 
If  an  unauthorized  party  obtains  the  card  number  in  any  way,  a  breach  of  confi¬ 
dentiality  has  occurred. 

Integrity  (I)  is  the  assurance  that  information  is  not  altered  in  an  unauthorized 
fashion.  For  example,  integrity  is  violated  when  an  employee  deletes  important 
data  files,  when  a  computer  virus  infects  a  computer,  or  when  an  employee  is  able 
to  modify  his  own  salary  in  a  payroll  database. 

Availability  (A)  is  the  assurance  that  information,  systems,  and  resources  are  avail¬ 
able  to  users  in  a  timely  manner  so  productivity  will  not  be  affected. 


access  to  attacks  that  assumed  corrupted 
clients.  These  attacks  focused  on  exploit¬ 
ing  specific  vulnerabilities,  therefore  pro¬ 
viding  the  least  amount  of  coverage  but 
the  most  amount  of  depth.  Figure  1  visu¬ 
alizes  our  approach  of  subjecting  the 
whole  system  to  a  set  of  low-cost  generic 
checks  to  maximize  coverage  while  per¬ 
forming  a  more  in-depth  analysis  on  care¬ 
fully  selected  parts  of  the  system.  As  the 
figure  indicates,  the  methodology  enables 
a  flexible  amount  of  testing  from  specific 
(i.e.,  to  the  requirements  of  the  tested  pro¬ 
gram)  to  generic  (i.e.,  testing  that  could  be 
applied  to  any  program)  and  from  narrow 
to  broad  coverage  of  the  tested  system. 
The  depth  and  coverage  of  the  testing  can 
be  chosen  to  enable  the  best  testing  possi¬ 
ble  in  given  time  and  budget  constraints. 

Static  Code  Analysis  and 
Memory  Profiling 

The  purpose  of  static  code  analysis  is  to 
automatically  flag  common  coding  errors 
that  leave  the  system  vulnerable  to 
exploits.  A  large  number  of  code  analysis 
algorithms  and  tools  for  finding  security 
vulnerabilities  exist,  including  both  com¬ 
mercial-  and  research-grade  tools,  with  dif¬ 
ferent  trade-offs  for  cost  and  effectiveness. 

We  utilized  several  analysis  tools  as 
part  of  our  research  efforts  (as  described 
in  the  following  text).  We  did  not  conduct 
a  comprehensive  comparison  of  the  avail¬ 
able  analysis  tools,  but  instead  selected  a 
representative  set  that  provided  useful 
analysis.  There  are  alternatives  to  the  par¬ 
ticular  tools  that  we  selected,  although  the 
amount  of  coverage  and  analysis  differs 
between  tools.  Furthermore,  we  concen¬ 
trated  on  tools  that  analyze  programs  writ¬ 
ten  in  Java  and  C++.  Arguably,  these  are 
the  most  common  languages  in  use  today 
and  are  the  languages  in  which  the  systems 
that  we  tested  were  written.  We  believe  the 
concepts  and  process  that  we  put  forward 
are  valid  for  any  language  (although  the  set 
of  available  tools  will  certainly  vary  and 
the  tools  for  languages  other  than  Java  and 
C++  might  be  less  readily  available). 

FindBugs  [2]  was  the  most  useful  tool 
for  us  when  analyzing  Java  code.  FindBugs 
uses  static  analysis  to  inspect  Java  byte 
code  for  occurrences  of  bug  patterns 
without  tire  need  to  execute  die  program. 
For  analyzing  C++  code,  we  used 
FlawFinder  [3]  and  RATS  [4]  open-source 
tools.  FlawFinder  is  a  program  that  exam¬ 
ines  source  code  and  reports  possible 
security  weaknesses  (flaws)  sorted  by  risk 
level.  It  is  useful  for  quickly  finding  and 
removing  some  potential  security  prob¬ 
lems  before  a  program  is  released.  RATS 


is  a  tool  for  scanning  C,  C++,  Perl,  PHP, 
and  Python  source  code,  and  for  flagging 
common  security-related  programming 
errors  such  as  buffer  overflows  and  time- 
of-check-to-time-of-use  race  conditions. 

In  order  to  detect  memory  leaks 
(which  can  adversely  affect  availability) 
and  memory  corruption  (which  can  be 
exploited  to  escalate  privilege  through 
buffer  overflow  attacks),  this  phase  of  the 
testing  process  runs  a  system  through  a  set 
of  memory  profiling  tools  that  keep  track 
of  dynamic  memory  allocations  and  per¬ 
form  analysis  to  detect  errors  during  oper¬ 
ation. 

For  C++  programs,  we  successfully 
used  Valgrind  [5],  Mudflap  [6],  and  mpa- 
trol  [7],  This  set  was  selected  to  maximize 
coverage  and  mitigate  errors  introduced  by 
individual  tools.  For  Java  programs,  the 


scope  of  memory  profiling  is  not  to  direct¬ 
ly  detect  bad  memory  conditions  (since 
Java  avoids  memory  corruption  and  leak 
issues  through  garbage  collection),  but  to 
provide  useful  debugging  functionality  in 
cases  where  Java  runs  out  of  memory. 

Stress  Testing 

The  goal  of  stress  testing  is  to  assess  sys¬ 
tem  functionality  under  application-level 
boundary  conditions,  such  as  high  load 
scenarios  with  large  information  objects, 
large  numbers  of  clients,  and  high  rates  of 
client  requests. 

Large  MIOs 

During  the  IMS  assessment,  we  studied 
whether  a  single  client  can  affect  the  avail¬ 
ability  of  the  IMS  server  by  publishing  a 
few  very  large  managed  information 


Figure  2:  Progression  of  Direct  Attacks  that  Compromise  CIA 
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objects  (MIOs)1.  To  study  the  impact  of 
MIO  size,  we  modified  an  existing  test 
client  to  publish  MIOs  with  various 
metadata  and  payload  sizes.  The  goal  of 
this  test  was  to  identify  the  boundary 
point  at  which  MIOs  get  rejected  by  the 
server  due  to  their  size.  For  scenarios 
with  no  active  subscriptions,  a  client  pub* 
lishing  an  MIO  with  a  combined  payload 
size  of  28MB  (payload  =  14MB  and 
metadata  =  14MB)  caused  exceptions  in 
the  core  IMS  and  sometimes  on  the  client 
side,  leading  to  loss  of  the  MIO.  This  was 
well  below  the  maximum  Java  Virtual 
Machine  (JVM)  memory  limits  of 
1024MB  on  both  the  client  and  server 
side  and  represented  an  inadvertent  inter¬ 
nal  size  limit  that  could  be  exploited  by 
rogue  clients.  In  a  follow-on  experiment, 
we  studied  the  impact  of  the  number  of 
active  subscriptions  on  the  maximum 
accepted  MIO  size.  One  active  subscrip¬ 
tion  reduced  the  maximum  MIO  size  to 
5.8MB,  while  only  MIOs  with  less  than 
2MB  could  be  delivered  to  two  sub¬ 
scribers.  The  expected  cause  was  prolific 
copy  operations  on  the  metadata  strings 
during  subscription  predicate  matching. 
The  IMS  code  has  been  tested  with  large 
payloads  but  never  with  MIOs  with  large 
metadata  based  on  an  undocumented 
assumption  that  metadata  is  usually  small 
compared  to  payloads.  While  this 
assumption  may  hold  in  practice  during 
normal  use,  it  is  the  type  of  assumption 
likely  to  be  exploited  by  a  determined 
adversary.  The  solution  to  this  problem  is 
to  refactor  the  code  to  avoid  duplication 
of  byte  arrays. 

Large  Number  of  Clients 

Another  stress  test  focused  on  evaluating 
the  impact  of  a  large  number  of  concur¬ 
rent  clients  on  IMS  server  availability.  For 
that  purpose,  we  simply  started  multiple 
publishing  clients  on  the  same  client  host. 
Out  of  memory  exceptions  occurred  in 
the  core  IMS  after  registering  36  clients, 
resulting  in  a  denial  of  service  to  all 
clients.  In  addition  to  identifying  a  point 
of  optimization  to  increase  the  number  of 
clients  supported,  this  test  also  pointed 

Figure  3:  TCP  Connection  Flooding  Attack 


out  a  survivability  and  security  need.  Since 
there  is  always  going  to  be  an  upper  limit 
to  the  number  of  clients  that  can  be  prop¬ 
erly  supported  by  a  single  server,  there 
should  be  code  in  the  server  that  checks 
the  number  of  clients  and  refuses  new 
clients  when  the  limit  is  reached. 

Direct  Attacks 

Adversaries  typically  don’t  start  from 
scratch  when  attacking  applications  and 
can  leverage  a  large  collection  of  openly 
available  tools  to  construct  customized 
multi-step  attacks  targeting  critical  appli¬ 
cation  functionality.  Figure  2  (see  previous 
page)  displays  a  progression  of  attacks 
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(with  an  increasing  level  of  privilege)  that 
an  adversary  might  follow  to  compromise 
CIA.  This  attack  sequence  crosses  multi¬ 
ple  system  and  protection  boundaries,  as  is 
common  during  sophisticated  attacks.  The 
following  subsections  describe  each  attack 
in  more  detail,  describe  observations 
made  during  test  attacks,  and  provide  sug¬ 
gestions  on  mitigation  strategies. 

Network  Sniffing 

Description:  Attackers  use  sniffing  to 
find  out  information  about  the  system  (for 
attack  purposes)  and  to  steal  sensitive 
information. 

Risk:  Loss  of  confidentiality  and  integri¬ 
ty- 

Figure  4:  Java  Serialisation  Attack 
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Example:  Wireshark  [8]  was  used  to  cap¬ 
ture  the  raw  content  of  packets  sent  out 
by  a  publishing  client  to  the  IMS  core. 
Although  the  IMS  uses  Transport  Layer 
Security  (TLS)  [9]  for  encrypting  data  on 
the  network  and  preventing  sniffing 
attacks,  it  was  noticed  that  TLS  was  only 
used  for  initial  authentication  and  connec¬ 
tion  establishment  between  clients  and  the 
server.  Published  MIOs  went  over  a  sepa¬ 
rate  Transmission  Control  Protocol  (TCP) 
connection  that  did  not  provide  TLS  pro¬ 
tection.  As  a  result,  the  IMS  was  vulnera¬ 
ble  to  a  loss  of  confidentiality  via  standard 
network  sniffing.  Furthermore,  attackers 
could  cause  integrity  violations  by 
exchanging  MIO  payloads  (e.g.,  swapping 
out  targets  in  a  target  nomination  list). 
Traffic  was  also  vulnerable  to  replay 
attacks,  which  are  a  special  form  of  data 
corruption  where  the  data  content  isn’t 
changed  but  corruption  is  still  introduced 
by  republishing  MIOs. 

Mitigation:  The  solution  to  these  vulner¬ 
abilities  is  protecting  all  communication 
between  clients  and  the  server  via  TLS, 
and  devising  automated  tests  that  classify 
all  observed  traffic. 

TCP  Connection  Flooding 

Description:  The  main  idea  of  the  TCP 
connection  flood  is  to  initiate  and  estab¬ 
lish  a  large  number  of  TCP  connections 
from  an  infiltrated  client  to  a  listening 
socket.  Since  servers  typically  set  aside 
memory  and  process  resources  for  new 
connections,  a  large  number  of  connec¬ 
tions  can  create  memory  exhaustion  in 
which  further  connections  from  legitimate 
clients  will  be  dropped.  The  top  of  Figure 
3  shows  die  normal  three-way  handshake 
during  TCP  connection  establishment.  A 
client  initiates  the  connection  via  a  syn¬ 
chronize  (SYN)  packet,  which  gets 
answered  by  the  server  with  a 
SYN / Acknowledge  (ACK)  packet.  Upon 
receiving  the  SYN /ACK  packet,  the  client 
replies  with  another  ACK  packet,  which 
establishes  the  TCP  connection. 

TCP  connection  floods  are  different 
from  SYN  floods,  in  which  the  client  sim¬ 
ply  goes  on  to  send  out  a  large  number  of 
SYN  packets  originating  either  from  the 
same  client  IP  address  or  multiple  ( spoofed) 
client  IP  addresses  without  completing  the 
three-way  handshake.  Each  SYN  packet 
needs  to  get  processed  by  the  server’s  TCP 
IP  stack;  such  a  situation  can  cause  mem¬ 
ory  and  CPU  exhaustion  in  the  server’s 
TCP  IP  stack.  Modern  operating  systems 
deal  with  SYN  floods  effectively  using 
SYN  cookies  [10]. 

Figure  3  displays  the  sequence  of 
events  during  a  TCP  connection  flooding 
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attack.  Here  the  client  completes  the 
three-way  TCP  handshake,  but  dten  keeps 
creating  new  connections.  A  straightfor¬ 
ward  version  of  this  attack  keeps  the 
client’s  source  IP  of  all  connections  the 
same,  whereas  more  sophisticated  ver¬ 
sions  can  spread  to  multiple  client  IPs. 
Note,  however,  that  this  escalation  cannot 
simply  be  achieved  through  IP  address 
spoofing,  since  tire  client  needs  to  get  the 
server’s  SYN /ACK  packet  routed  to  it  in 
order  to  proceed.  Since  each  established 
connection  generally  causes  application 
resources  to  be  used  (e.g.,  threads  and 
associated  memory  structures),  a  large 
number  of  connections  can  cause  applica¬ 
tions  to  run  out  of  memory,  causing  legit¬ 
imate  clients  to  fail. 

Risk:  Loss  of  availability. 

Example:  In  an  experiment  to  assess  the 
IMS  software’s  vulnerabilities  to  TCP  con¬ 
nection  floods,  we  used  an  attack  client 
that  established  and  held  1,200  TCP  con¬ 
nections,  and  studied  the  effect  of  point¬ 
ing  this  client  to  each  of  1 5  listening  ports 
in  separate  runs.  The  results  were  interest¬ 
ing.  The  maximum  number  of  established 
connections  varied  across  ports  (from  60 
to  753)  as  did  attack  effects.  This  included: 

•  A  loss  of  publish  functionality. 

•  A  loss  of  administration  functionality. 

•  A  loss  of  system  access  on  the  node 
running  the  IMS  server  process  due  to 
maximum  file  handle  limits. 

•  Denial-of-service  through  disk  ex¬ 
hausting  via  large  log  files. 

•  No  log  generation  for  floods  on  cer¬ 
tain  ports,  enabling  attackers  to  exe¬ 
cute  stealthy  attacks  that  are  hard  to 
diagnose. 

Mitigation:  A  threshold  scheme  taking 
into  account  the  source  IP  of  the  connec¬ 
tion  together  with  past  connection  history 
makes  execution  of  this  attack  significant¬ 
ly  harder.  In  addition,  code  to  limit  the 
rate  of  outgoing  TCP  connections  from 
legitimate  clients  helps  prevent  such  con¬ 
ditions  in  the  case  of  accidental  applica¬ 
tion  programming  interface  misuse  in 
client  programs.  Furthermore,  ports  that 
only  require  local  access  (e.g.,  5400) 
should  be  bound  to  127.0.0.1  instead  of 
0.0.0.0  to  prevent  remote  execution  of 
connection  flooding  attacks.  Finally,  all 
code  should  be  augmented  with  proper 
exception  handling  to  generate  a  small 
number  of  succinct  exceptions  in  flooding 
conditions. 

Serialization  Attacks 

Description:  This  attack  exploits  known 
type  safety  issues  Java  programs  encounter 
during  deserialization.  Creating  and  send¬ 
ing  a  special  serialized  Java  object  to  a 


Server 


Figure  5:  Direct  Calls  on  MBeans  Without  Authentication 


remote  method  invocation  (RMI)  server 
port  (as  shown  in  Figure  4)  allows  attack¬ 
ers  to  remotely  exploit  JVM  bugs  and 
cause  client-initiated  execution  of  arbi¬ 
trary  code. 

Risk:  Loss  of  CIA. 

Example:  Let’s  consider  the  following 
server  code  snippet  used  for  reading 
objects  off  the  network,  as  described  in 
[11]: 

mySocket  =  new  ServerSocket(3000); 
while  (true)  { 

Socket  client  =  mySocket.accept(); 
ReceiveRequest  dtwt  =  new  Receive 
Request  (client); 

} 

class  Request  implements  Serializable  { } 
class  ReceiveRequest  extends  Thread{ 
Socket  clientSocket  =  null ; 
ObjectlnputStream  ois  =  null; 
ReceiveRequest  (Socket  theClient) 
throws  Exception  { 

clientSocket  =  theClient; 

//  get  the  Streams 
ois  =  new 

ObjectlnputStream(clientSocket. 
get  lnputStream()); 

} 

public  void  run()  { 
try  { 

Request  ac  =  (Request) 
t=2 

ois.readObject(); } 
t=1 

catch  (Exception  e) 

{  System.out.println(e) ; } 

//... 

} 

} 

Note  how  the  server  first  reads  in  the 
Object  (t=1)  and  then  performs  the  cast  to 
the  expected  Request  type  (t=2).  The  gen¬ 
erated  byte  code  shows  the  following  exe¬ 
cution  sequence: 

public  void  run(); 

Code: 

0:  aload  0 


t=1  1:  getfield  #3; //Field 

ois:Ljava/io/Object 

InputStream; 

4:  invokevirtual  #7;  //Method 

java/io/ObjectlnputStream. 

readObject:() 

Ljava/lang/Object; 

t=2  7:  checkcast  #8;  //class  Request 

10:  astorejl 
11:  goto  22 
14:  astore  1 


The  sequence  of  events  is  as  follows: 

•  t=0  client  sends  byte  stream  (serialized 
object  data)  via  ObjectlnputStream. 

•  t=1  Server  branches  into  the 
readObject  method  of  the  class 
according  to  the  result  returned  by 
getfield. 

•  t=2  server  casts  the  object  to  the  need¬ 
ed  type. 

o  Cast  is  valid:  continue  work, 
o  Cast  is  invalid:  throw  ClassCast 
Exception. 

Between  t=0  and  t=2,  there  is  no  type 
safety.  The  client  gets  to  decide  (at  t=0) 
which  code  the  server  branches  into  (at 
t=1).  This  opens  up  an  attack  path  in  con¬ 
junction  with  an  existing  vulnerability  of  a 
readObject  method  on  any  class  drat  is  on 
the  server’s  load  path.  First,  attackers  can 
find  some  vulnerable  class  definitions  on 
the  server  (especially  in  a  readObject 
method,  any  serializable  class  will  do). 
Next,  they  can  construct  an  object  accord¬ 
ing  to  dris  class  definition  and  finally 
embed  the  malicious  object  in  the 
ObjectlnputStream  payload  of  the  Java  2 
Platform  Enterprise  Edition  (J2EE)  pro¬ 
tocol  (RMI,  RMI/Internet  Inter-Orb 
Protocol,  Java  Naming  and  Directory 
Interface  [JNDI],  and  so  forth). 
Serialization  attacks  have  been  used  fre¬ 
quently  in  the  past:  see  [11]  for  regular 
expression  exploits  and  [12]  for  exploiting 
hash  table  collisions. 

Mitigation:  Our  suggestions  to  prevent 
serialization  vulnerabilities  involve  careful 
review  and  minimization  of  loadable 
classes  on  the  server’s  classpath.  In  addi- 
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tion,  a  crumple  zone — a  layer  of  proxy 
components  that  anyone  seeking  service 
must  go  through — can  be  deployed  to 
perform  the  deserialization  of  all  objects 
entering  the  core.  Augmenting  proxies 
with  proper  monitoring  and  restart  capa¬ 
bilities,  and  introducing  diversity  through 
different  JVM  implementations  and  pro¬ 
gramming  languages,  will  help  reduce  the 
dangers  of  this  attack  type. 

MBean  Backdoors 

Description:  This  attack  attaches  a 
remote  client  to  the  managed  beans 
(MBeans)  available — via  Java  Management 
Extensions  inside  of  a  J2EE  server — and 
makes  dynamic  calls  into  the  server  with¬ 
out  the  need  for  authentication.  As  shown 
in  Figure  5  (see  previous  page),  clients  can 
make  direct  calls  on  MBeans  handled  by  a 
JBoss  Application  Server  (AS)  by  simply 
performing  a  lookup,  creating  an 
RMIAdaptor  connection,  and  making  RMI 
calls. 

Risk:  Loss  of  CIA. 

Example:  In  the  IMS  code,  clients  could 
directly  connect  to  the  MBeans  via 
jmx/invoker/RMIAdaptor  and  make  calls 
through  the  MBeanServerConnection 
without  needing  to  authenticate.  This 
would  enable  calls  that  could  remove  all 
repositories,  inject  a  man-in-the-middle 
master  repository  (loss  of  confidentiality), 
and  change  security  policies  (loss  of 
integrity),  for  example.  No  logging  is  per¬ 
formed  during  these  remote  calls,  which 
makes  this  attack  very  stealthy. 
Mitigation:  To  prevent  this  attack,  one 
needs  to  harden  access  to  127.0.0.1: 
8080/invoker/JNDIFactory  and  lookup  of 
jvm/invoker/RMIAdaptor.  Using  TLS  and 
binding,  the  listening  socket  to  127.0.0.1 
only  will  make  access  by  unauthorized 
clients  more  difficult.  In  addition,  tighter 


integration  of  the  socket  listener  on  port 
8080  with  security  handling  code  helps 
prevent  this  attack. 

Password  Cracking 

Description:  This  attack  guesses  correct 
passwords  through  repetitive  trials  of 
passwords  retrieved  from  common  attack 
dictionaries.  Once  the  valid  administrator 
password  has  been  determined,  the  adver¬ 
sary  can  simply  log  in  as  the  administrator 
and  perform  all  actions  normally  granted 
to  administrators,  including  deletion  of 
critical  MIOs  and  removal  of  users. 

Risk:  Loss  of  CIA. 

Example:  The  prototype  IMS  code  was 
susceptible  to  brute  force  password 
attacks  because  it  allowed  attack  scripts  to 
try  an  unlimited  number  of  password 
combinations  without  impacting  account 
status.  No  log  events  occurred  in  the 
JBoss  AS  console  when  authentication 
failed,  making  the  attack  difficult  to  detect. 
Mitigation:  An  effective  approach  to 
counter-password  attacks  is  to  establish  a 
cutoff  scheme  in  which  accounts  are 
locked  down  after  a  specific  number  of 
failed  login  attempts.  In  addition,  failed 
login  attempts  should  be  logged  to  a  man¬ 
agement  station. 

Malformed  XML 

Description:  These  attacks  attempt  to 
deny  service  to  legitimate  clients  by  taking 
over  a  single  client  and  publishing  mal¬ 
formed  XML  input  data  with  the  intent  to 
crash  the  server. 

Risk:  Loss  of  availability. 

Example:  We  tested  the  vulnerability  of 
the  prototype  IMS  to  this  kind  of  attack 
by  modifying  the  client  to  publish  MIOs 
with  improperly  formatted  metadata. 
XML  validation  properly  caught  and  han¬ 
dled  the  bad  content.  Next,  we  tried 


uploading  a  malformed  schema  and 
observed  the  following  issues: 

•  Schemas  were  properly  validated,  but 
validation  exceptions  cause  ClassNot- 
FoundExceptions. 

•  Schemas  that  don’t  start  with  <?xml 
version  passed  validation  but  caused 
errors  during  publication. 

•  Schemas  with  duplicate  xsd:schema 
lines  passed  validation  but  cause  Null 
Pointer  Exceptions  in  the  Berkeley  DB 
XML  backend,  and  cause  Web  console 
access  to  the  Interoperable  Object 
Reference  to  fail. 

These  issues  are  easy  to  fix  but  are 
indicative  of  the  bugs  that  can  creep  in, 
even  when  XML  content  is  validated 
through  schemas  but  the  schema  itself  is 
not. 

Mitigation:  The  use  of  restrictive  XML 
schemas  and  validation  of  all  XML  input 
against  them  goes  a  long  way  in  addressing 
this  vulnerability. 

SQL  Injection 

Description:  SQL  injection  is  a  technique 
that  exploits  a  security  vulnerability  occur¬ 
ring  in  the  database  layer  of  an  applica¬ 
tion.  The  vulnerability  is  present  when 
user  input  is  either  incorrectly  filtered  for 
string  literal  escape  characters  embedded 
in  SQL  statements  or  user  input  is  not 
strongly  typed  and,  thereby,  unexpectedly 
executed.  It  is  (in  fact)  an  instance  of  a 
more  general  class  of  vulnerabilities  that 
can  occur  whenever  one  programming  or 
scripting  language  is  embedded  inside 
another. 

Risk:  Loss  of  CIA. 

Example:  Figure  6  displays  the  normal 
flow  of  data  from  a  client  via  a  server  to 
the  backend  SQL  DB.  If  the  data  sent  by 
the  client  is  not  filtered  before  reaching 
the  SQL  DB,  the  client  can  execute  arbi¬ 
trary  commands  on  it. 

Figure  7  depicts  one  such  example  that 
was  used  by  attackers  during  the  2005 
OASIS  Dem/Val  red  team  exercise  [13]. 
The  attack  locked  up  servers  by  inserting  a 
BENCFIMARK  command,  which  would 
cause  the  SQL  DB  to  use  100  percent  of 
the  available  CPUs.  The  BENCFIMARK 
command  causes  MySQL  (a  relational 
database  management  system)  to  run 
through  an  extensive  set  of  mathematical¬ 
ly  expensive  computations,  pre-empting 
useful  computation  for  hours. 

Our  testing  indicated  that  the  proto¬ 
type  IMS  code  was  not  vulnerable  to  SQL 
injection  attacks. 

Mitigation:  To  prevent  SQL  injection 
attacks,  user  interfaces  should  be  designed 
to  be  as  restrictive  as  possible  (e.g.,  a  selec¬ 
tion  menu  instead  of  free  text  entry,  and 


Figure  6:  Data  Propagation  to  SOD  Databases  (SQDDBs) 
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Figure  7:  Example  SQL  Injection  Attack 
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Software  Defense  Application 

This  article  describes  survivability  assessment  techniques  that  will  benefit  the  defense 
software  community  through  more  flexible  design  evaluations,  more  useful  assess¬ 
ments,  and  reduced  time  in  identifying  and  mitigating  vulnerabilities.  The  in-depth 
analysis  of  the  most  prevalent  cyberattack  scenarios  will  help  defense  software  devel¬ 
opers  understand  what  they  may  encounter;  but,  more  importantly,  the  authors  pre¬ 
sent  first-hand  accounts  detailing  how  they  solved  these  problems.  The  end  result  is 
a  significant  increase  in  a  system’s  overall  security. 


all  user  input  should  be  checked  for 
embedded  SQL  commands). 

XPathIXQuery  Injection 

Description:  This  attack  attempts  to  gain 
the  same  effects  described  in  the  SQL 
injection  attack  by  providing  specially 
crafted  query  predicates. 

Risk:  Loss  of  CIA. 

Example:  The  following  code  fragment 
shows  an  example  in  which  the  client 
explicitly  specifies  parts  of  the  XQuery 
that  usually  gets  implicitly  generated  and 
executed  by  the  IMS  server: 

connection.createQuerySequence 

(“mil.af.rl.oim.training.xmlx- 
path”,  “1.0”); 

String  xmlxpathPredicate  = 

Uti  Is.createPred  icate 
(“TestPredicate”,  “XQuery”, 

“for  $a  in 

collection(\”SCHEMA_422547673.dbxml\”) 
/child::sys:Metadata 
where  ($a//ATO/type  =  Y’ATOV’) 

returndbxml  :metadata(\”dbxml  :name\”, 
$a)”); 

XPath  injection  attacks  proved  partial¬ 
ly  effective  against  the  prototype  IMS, 
partly  because  it  dynamically  constructed 
and  executed  XQuery  statements  from 
XPath  input.  Custom  XQuery  predicates 
allow  a  small  amount  of  information  exfil¬ 
tration.  For  instance,  an  attack  client  could 
probe  through  repeated  queries  to  deter¬ 
mine  whether  air  task  orders  (ATOs)  were 
available  with  certain  metadata  fields, 
although  the  client  could  not  actually 
retrieve  the  ATO  payload.  In  addition,  the 
IMS,  which  explicitly  prohibited  full 
XQuery  predicates  because  of  their  ability 
to  modify  the  database,  included  a  backdoor 
through  which  full  XQuery  commands 
could  be  sent  to  the  database.  This  only 
presented  a  vulnerability  if  the  backdoor 
code  persisted  through  releases  of  the 
code.  In  addition  to  vulnerabilities  to  the 
IMS  database,  XQuery  is  a  powerful  lan¬ 
guage,  allowing  (in  principle)  direct  calls 
into  the  JVM  through  external  functions. 
This  would  allow  an  attacker,  for  instance, 
to  call  System. exit(-l)  through  a  specially 
crafted  query.  The  prototype  IMS  did  not 
exhibit  this  vulnerability  because  it  used  an 
earlier  version  of  XQuery  that  did  not 
support  embedded  Java  functions. 
Mitigation:  To  prevent  XQuery  exploits, 
all  user  input  should  be  checked  for  dan¬ 
gerous  XQuery  commands,  such  as 
delete,  update,  and  references  to  external 
functions. 


Simulated  Node  Failures 

Description:  A  common  survivability 
experiment  involves  studying  the  impact 
of  crashes  of  one  component  on  other 
components.  However,  it  can  be  difficult 
to  devise  an  attack  that  is  so  precise  that  it 
crashes  only  the  targeted  component. 
Therefore,  this  attack  uses  fault  injection 
techniques  to  simply  cause  the  desired 
fault  (e.g.,  by  manually  stopping  a  compo¬ 
nent)  . 

Risk:  Sustained  loss  of  availability. 
Example:  We  injected  crash  faults  in  the 
IMS  database  (Berkeley  DB  XML)  by 
sending  the  database  a  kill  -9  signal.  The 
IMS  did  not  contain  a  monitoring  proto¬ 
col  to  test  the  liveliness  of  processes.  An 
accidental  crash  of  the  Berkeley  DB  XML 
process  led  to  situations  in  which  the  IMS 
server  was  unavailable,  and  the  situation 
was  noticed  only  when  critical  operations 
started  failing. 

Mitigation:  A  secure,  heartbeat-based 
monitor  that  provides  low  failure  detec¬ 
tion  latencies  and  is  resistant  to  spoofing 
attacks.  The  monitor  can  reduce  the 


impact  and  speed  the  recovery  from  these 
attacks. 

Results  and  Summary 

Table  1  displays  a  summary  of  both  stress 
tests  and  direct  attacks  conducted,  their 
results,  and  their  effects  on  CIA. 

In  summary,  nine  of  the  1 1  tests  were 
successful  in  achieving  attack  objectives. 
Risks  to  confidentiality  were  exposed  in 
five  tests,  which  is  a  surprisingly  high 
number  given  that  it  is  generally  much  eas¬ 
ier  to  cause  a  denial  of  service  than  to 
exfiltrate  data  without  being  detected.  The 
experiment  generated  new  requirements 
for  the  IMS — both  in  terms  of  fixing  bugs 
and  ease-of-use  issues  as  well  as  in 
addressing  deeper  problems,  including  a 
single  point  of  failure  for  various  compo¬ 
nents,  lack  of  adequate  management  tools, 
and  susceptibility  to  direct  attacks 

This  article  presented  a  flexible 
process  for  evaluating  systems  early  on  in 
their  life  cycles  for  information  survivabil¬ 
ity  and  showed  its  application  during  an 
assessment  of  a  prototype  PSQ  informa¬ 
tion  management  system.  This  work 


Table  1:  IMS  Assessment  Results 


Test 

Result 

Effect* 

Large  MIOs 

Out  of  memory  errors  with  IOs  over  md  =  14MB,  pi  =  14MB, 

0  subscribers  md  =  5.8MB,  pi  =  5.8MB, 

1  subscriber  md  =  2MB,  pi  =  2MB,  2  subscribers. 

A 

Large  Number  of 
Clients 

Out  of  memory  errors  after  registration  of  36  clients. 

A 

Network  Sniffing 

MIOs  are  sent  in  the  clear. 

Cl 

TCP  Connection 
Flooding 

Denial-of-service  without  generating  log  entries. 

A 

Serialization  Attacks 

Clients  can  execute  arbitrary  code  in  the  JVM  without 
authentication. 

CIA 

MBean  Backdoors 

Clients  can  make  anonymous  calls  on  MBeans. 

CIA 

Password  Cracking 

Brute-force  password  testing  at  the  rate  of  100  per  second. 

Cl 

Malformed  User  Data 

Apollo  resilient  against  malformed  metadata  and  schemas. 

None 

SQL  Injection 

Suspicious  SQL  code  turns  out  to  be  dead  code. 

None 

XQuery  Injection 

Unauthorized  access  to  MIOs  and  execution  of  arbitrary  code. 

CIA 

Simulated  Node 
Failures 

Absence  of  monitoring  protocol. 

A 

*C  =  Confidentiality,  I  =  Integrity,  A  =  Availability  pi  =  Payload,  md  =  Metadata 
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builds  upon  previous  and  ongoing 
research  in  survivable  distributed  systems 
and  addresses  the  current  and  future  need 
to  effectively  and  accurately  evaluate  sys¬ 
tem  guarantees  in  the  presence  of  sophis¬ 
ticated  cyberattacks.  We  have  packaged  a 
number  of  reusable  attack  techniques  and 
associated  tools  that  can  be  customized 
for  new  systems  with  little  overhead. 

Next  Steps 

Our  future  research  will  continue  to  build 
upon  the  work  presented  in  this  article  in 
two  ways. 

First,  we  plan  to  extend  our  assess¬ 
ment  approach  by  adding  more  techniques 
and  automating  customization  and 
automation  aspects  of  attack  scenarios. 
This  will  further  reduce  overhead  costs  for 
assessments  and  increase  their  frequency 
during  a  project  life  cycle.  We  clearly  see 
tire  value  of  establishing  a  community- 
based  collaboration  platform  for  surviv¬ 
ability  assessments  (e.g.,  those  hosted  on 
<https://www.forge.mil>).  As  more  pro¬ 
jects  start  using  the  techniques  described 
in  diis  article,  system  survivability  require¬ 
ments  will  need  to  be  taken  into  account 
as  systems  need  to  provide  different  levels 
of  survivability.  More  research  is  needed 
to  develop  a  point/scoring  system  that 
evaluates  survivability  in  a  systematic  and 
quantitative  way — given  the  security  pos¬ 
ture  and  criticality  of  an  application. 

Second,  we  plan  on  investigating  solu¬ 
tions  to  the  deeper  problems  of  die  exis¬ 
tence  of  single  points  of  failures  and  the 
lack  of  adequate  management  tools.  For 
future  work  in  service-oriented  informa¬ 
tion  management  systems,  we  intend  to: 

1.  Extend  service-oriented  architecture 
and  design  techniques  to  include  secu¬ 
rity  and  survivability  concepts  that 
facilitate  survivable  designs. 

2.  Develop  security  services,  mecha¬ 
nisms,  and  execution  containers  for 
preserving  system  CIA  in  the  presence 
of  cyberattacks. 

3.  Develop  an  environment  to  assess  and 
evaluate  composition  patterns,  en¬ 
abling  customization  of  tradeoffs 
between  survivability,  performance, 
and  functionality  for  specific  environ¬ 
ments.  ♦ 
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The  goal  of  software  security  engineering  is  to  build  better,  defect  free  software.  The  book  “Software  Security  Engineering:  A 
Guide  for  Project  Managers”  [l]1 — and  its  key  resource,  the  Build  Security  In  (BSI)  Web  site — provide  software  project 
managers  with  sound  practices  that  they  can  evaluate  and  selectively  adopt  to  help  reshape  their  own  development  practices. 
Software  developed  and  assembled  using  these  practices  should  contain  significantly  fewer  exploitable  weaknesses. 


Software  is  ubiquitous.  Many  of  the 
products,  services,  and  processes  that 
organizations  use  and  offer  are  highly 
dependent  on  software  to  handle  die  sen¬ 
sitive  and  high-value  data  on  which  peo¬ 
ple’s  privacy,  livelihoods,  and  very  lives 
depend.  National  security  relies  on 
increasingly  complex,  interconnected, 
software-intensive  information  systems — 
systems  that  (in  many  cases)  use  the 
Internet  or  Internet-exposed  private  net¬ 
works  as  their  means  for  communication 
and  transporting  data. 

Dependence  on  IT  makes  software 
security  a  key  element  of  business  conti¬ 
nuity,  disaster  recovery,  incident  response, 
and  national  security.  Software  vulnerabil¬ 
ities  can  jeopardize  intellectual  property, 
consumer  trust,  business  operations  and 
services,  and  a  broad  spectrum  of  critical 
applications  and  infrastructures,  including 
everything  from  process  control  systems 
to  commercial  application  products. 

The  integrity  of  critical  digital  assets 
(systems,  networks,  applications,  and 
information)  depends  on  the  reliability 
and  security  of  the  software  that  enables 
and  controls  those  assets.  However,  busi¬ 
ness  leaders  and  informed  consumers 
have  growing  concerns  about  die  scarcity 
of  practitioners  with  requisite  competen¬ 
cies  to  address  software  security  [2],  They 
have  concerns  about  suppliers’  capabilities 
to  build  and  deliver  secure  software  that 
can  be  used  with  confidence  and  without 
fear  of  compromise.  Application  software 
is  the  primary  gateway  to  sensitive  infor¬ 
mation.  According  to  die  Deloitte  survey 
of  169  major  global  financial  institutions, 
current  application  software  countermea¬ 
sures  are  no  longer  adequate — application 
security  is  the  number  one  issue  for  chief 
information  officers  [3], 

The  absence  of  security  discipline  in 
today’s  software  development  practices 
often  produces  software  with  exploitable 
weaknesses.  Security-enhanced  processes 
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and  practices — and  the  skilled  people  to 
manage  and  perform  them — are  required 
to  build  software  that  can  be  trusted  to 
operate  more  securely  than  the  software 
being  used  today. 

That  being  said,  there  is  an  economic 
counterargument,  or  at  least  the  percep¬ 
tion  of  one.  Some  business  leaders  and 
project  managers  believe  that  developing 
secure  software  slows  the  process  and 
adds  to  die  cost  while  not  offering  any 
apparent  advantage.  In  many  cases,  when 


“Security-enhanced 
processes  and  practices 
...  are  required  to  build 
software  that  can 
be  trusted  to  operate 
more  securely  than 
the  software  being 
used  today.” 


die  decision  reduces  to  ship  now  or  be  secure 
and  ship  later,  ship  now  is  almost  always  the 
choice  made  by  those  who  control  the 
money  but  have  no  idea  of  die  risks. 
Information  combating  this  argument — 
showing  ways  software  security  has  led  to 
cost  and  schedule  reduction  and  docu¬ 
mented  successful  experiences  (e.g., 
Microsoft’s  Security  Development 
Lifecycle) — is  out  there. 

The  Goal  of  Software  Security 
Engineering 

Software  security  engineering  is  using 
practices,  processes,  tools,  and  techniques 
for  addressing  issues  in  every  phase  of  the 
software  development  life  cycle  (SDLC). 
Software  that  is  developed  with  security  in 
mind  is  typically  more  resistant  to  both 


intentional  attack  and  unintentional  fail¬ 
ures.  One  view  of  secure  software  is  diat 
software  is  engineered  “so  diat  it  contin¬ 
ues  to  function  correcdy  under  malicious 
attack”  [4]  and  is  able  to  recognize,  resist, 
tolerate,  and  recover  from  events  that 
intentionally  threaten  its  dependability. 
Broader  views  that  can  overlap  with  soft¬ 
ware  security  (e.g,  software  safety,  reliabil¬ 
ity,  and  fault  tolerance)  include  proper 
functioning  in  the  face  of  unintentional 
failures  or  accidents,  inadvertent  misuse 
and  abuse,  and  software  defect  and  weak¬ 
ness  reduction  to  die  greatest  extent  pos¬ 
sible  (regardless  of  its  cause). 

The  goal  of  software  security  engi¬ 
neering  is  to  build  better,  defect-free  soft¬ 
ware.  Software-intensive  systems  diat  are 
constructed  using  more  securely  devel¬ 
oped  software  are  better  able  to: 

•  Continue  operating  correctly  in  the 
presence  of  most  attacks  by  either 
resisting  die  exploitation  of  weakness¬ 
es  in  the  software  or  tolerating  the  fail¬ 
ures  diat  result  from  such  exploits. 

•  Limit  die  damage  from  attack-trig¬ 
gered  fault  failures  that  the  software 
was  unable  to  resist — or  tolerate  and 
recover  quickly  from  those  failures. 

Software  Security  Practices 

No  single  practice  offers  a  universal  silver 
bullet  for  software  security.  With  this  in 
mind,  “Software  Security  Engineering” 
provides  software  project  managers  with 
sound  practices  that  they  can  evaluate  and 
selectively  adopt  to  help  reshape  their  own 
development  practices.  The  objective  is  to 
increase  the  security  and  dependability  of 
the  software  produced  by  these  practices, 
both  during  its  development  and  its  oper¬ 
ation. 

The  book — and  material  referenced 
on  die  BSI  Web  site  at  <https:/ /build 
securityin.us-cert.gov> — identify  and 
compare  potential  new  practices  that  can 
be  adapted  to  augment  a  project’s  current 
software  development  practices.  These 
resources  also  greatly  increase  the  likeli- 
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hood  of  producing  more  secure  software 
and  meeting  specified  security  require¬ 
ments.  As  one  example,  assurance  cases 
can  be  used  to  assert  and  specify  desired 
security  properties,  including  tire  extent  to 
which  security  practices  have  been  suc¬ 
cessful  in  satisfying  security  requirements. 

Software  developed  and  assembled 
using  software  security  practices  should 
contain  significantly  fewer  exploitable 
weaknesses.  Such  software  can  be  relied 
on  to  more  capably  recognize,  resist  or 
tolerate,  and  recover  from  attacks — in 
turn  functioning  more  securely  in  an  oper¬ 
ational  environment.  Project  managers 
responsible  for  ensuring  that  software  and 
systems  adequately  address  their  security 
requirements  throughout  die  SDLC  can 
review,  select,  and  tailor  guidance  from  the 
book  and  Web  site  as  part  of  normal  pro¬ 
ject  management  activities. 

The  five  key  takeaways  from  the  book 
are  as  follows: 

1.  Software  security  is  about  more  than 
eliminating  vulnerabilities  and  con¬ 
ducting  penetration  tests.  Project  man¬ 
agers  need  to  take  a  systematic 
approach  to  incorporate  sound  soft¬ 
ware  security  practices  into  their  devel¬ 
opment  processes.  Examples  include 
security  requirements  elicitation,  attack 
pattern  and  misuse/ abuse  case  defini¬ 
tion,  architectural  risk  analysis,  secure 
coding  and  code  analysis,  and  risk- 
based  security  testing. 

2.  Network  security  mechanisms  and  IT 
infrastructure  security  services  do  not 
sufficiently  protect  application  soft¬ 
ware  from  security  risks. 

3.  Software  security  initiatives  should  fol¬ 
low  a  risk  management  approach  to 
identify  priorities  and  what  is  good 
enough,  understanding  that  software 
security  risks  will  change  throughout 
the  life  cycle.  Risk  management 
reviews  and  actions  are  conducted 
during  each  SDLC  phase. 

4.  Developing  secure  software  depends 
on  understanding  the  operational  con¬ 
text  in  which  it  will  be  used.  This  con¬ 
text  includes  conducting  end-to-end 
analysis  of  cross-system  work  process¬ 
es,  working  to  contain  and  recover 
from  failures  using  lessons  learned 
from  business  continuity,  and  explor¬ 
ing  failure  analysis  and  mitigation  to 
deal  with  system  and  system-of-sys- 
tems  complexity. 

5.  Project  managers  and  software  engi¬ 
neers  need  to  think  like  an  attacker  in 
order  to  address  the  range  of  tilings 
that  software  should  not  do  and  how 
software  can  better  resist,  tolerate,  and 
recover  when  under  attack.  The  use  of 


attack  patterns  and  misuse/ abuse 
cases  throughout  the  SDLC  encour¬ 
ages  this  perspective. 

Practice  Maturity  and 
Relevance 

As  a  community,  we  recognize  that  some 
software  security  practices  are  in  broader 
use  and  thus  more  tested  and  mature  than 
others,  such  as  security  coding  practices 
and  vulnerability  testing.  As  a  practice 
description  and  selection  aid,  descriptive 
tags  mark  the  book’s  sections  and  key 
practices  in  two  practical  ways: 

1.  Identifying  the  content’s  relative  matu¬ 
rity  of  practice  as  follows: 

•  Maturity  Level  1  (LI):  The  con¬ 
tent  provides  guidance  for  how  to 
drink  about  a  topic  for  which  there 


“Software  developed 
and  assembled  using 
software  security 
practices  should 
contain  significantly 
fewer  exploitable 
weaknesses  ...” 


is  no  proven  or  widely  accepted 
approach.  The  intent  of  the 
description  is  to  raise  awareness 
and  aid  in  thinking  about  the  prob¬ 
lem  and  candidate  solutions.  The 
content  may  also  describe  promis¬ 
ing  research  results  that  may  have 
been  demonstrated  in  a  con¬ 
strained  setting. 

•  Maturity  Level  2  (L2):  The  con¬ 
tent  describes  practices  that  are  in 
early  pilot  use  and  are  demonstrat¬ 
ing  some  successful  results. 

•  Maturity  Level  3  (L3):  The  con¬ 
tent  describes  practices  diat  are  in 
limited  use  in  industry  or  govern¬ 
ment  organizations,  perhaps  for  a 
particular  market  sector. 

•  Maturity  Level  4  (L4):  The  con¬ 
tent  describes  practices  that  have 
been  successfully  deployed  and  are 
in  widespread  use.  These  practices 
can  be  used  with  confidence. 
Experience  reports  and  case  stud¬ 
ies  are  typically  available. 

2.  Identifying  the  designated  audiences 
for  which  each  chapter  section  or  prac¬ 
tice  is  most  relevant: 


•  E:  Executive  and  senior  managers. 

•  M:  Project  and  mid-level  managers. 

•  L:  Technical  leaders,  engineering 
managers,  first-line  managers,  and 
supervisors. 

Build  Security  In:  A  Key 
Resource 

Since  2004,  the  DHS  Assurance  Program 
has  sponsored  development  for  tire  BSI 
Web  site,  a  significant  resource  used  in 
developing  “Software  Security  Engineer¬ 
ing.”  BSI  content,  referenced  throughout 
the  book,  is  based  on  the  principle  that 
software  security  is  fundamentally  a  soft¬ 
ware  engineering  problem  and  must  be 
managed  in  a  systematic  way  throughout 
the  SDLC. 

BSI  both  contains  and  links  to  a  broad 
range  of  information  about  sound  prac¬ 
tices,  tools,  guidelines,  rules,  principles,  and 
other  knowledge  to  help  project  managers 
deploy  software  security  practices  and  build 
secure  and  reliable  software.  Contributing 
authors  to  dais  book  and  articles  appearing 
on  dae  BSI  site  include  senior  staff  from 
the  SEI  and  Cigital,  Inc. 

Readers  can  consult  BSI  for  additional 
details,  ongoing  research  results,  and  infor¬ 
mation  about  related  Web  sites,  books,  and 
articles. 

Start  the  Journey 

As  software  and  security  professionals,  we 
will  never  be  able  to  get  ahead  of  dae  game 
by  addressing  security  solely  as  an  opera¬ 
tional  issue.  Attackers  are  creative,  inge¬ 
nious,  and  increasingly  motivated  by  finan¬ 
cial  gain.  They  have  been  learning  how  to 
exploit  software  for  several  decades;  the 
same  is  not  true  for  software  engineers,  and 
we  need  to  change  dais.  Given  dae  extent  to 
which  nations,  economies,  businesses,  and 
families  rely  on  software  to  sustain  and 
improve  dae  quality  of  life,  we  must  make 
significant  progress  in  putting  higher  quali¬ 
ty  and  more  secure  software  into  produc¬ 
tion.  The  practices  described  in  “Software 
Security  Engineering”  serve  as  a  useful 
starting  point. 

Each  project  manager  needs  to  careful¬ 
ly  consider  dae  knowledge,  skills,  and  com¬ 
petencies  of  their  development  team,  their 
organizational  culture’s  tolerance  (and 
attention  span)  for  change,  and  dae  degree 
to  which  sponsoring  executives  have 
bought  in  (a  prerequisite  for  sustaining  any 
improvement  initiative).  In  some  cases,  it 
may  be  best  to  start  with  secure  software 
coding  and  testing  practices:  They  are  dae 
most  mature,  have  a  fair  level  of  automat¬ 
ed  support,  and  can  demonstrate  some 
early  successes,  providing  visible  benefits  in 
helping  software  security  efforts  gain  sup- 
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port  and  build  momentum.  On  the  other 
hand,  secure  software  requirements  engi¬ 
neering  and  architecture  and  design  prac¬ 
tices  offer  opportunities  to  address  more 
substantive  root  cause  issues  early  in  die 
life  cycle  that,  if  left  unaddressed,  will  show 
up  in  the  code  and  test  phase.  Practice 
selection  and  tailoring  are  specific  to  each 
organization  and  project  based  on  objec¬ 
tives,  constraints,  and  die  criticality  of  die 
software  under  development. 

Project  managers  and  software  engi¬ 
neers  need  to  develop  a  better  understand¬ 
ing  of  what  constitutes  secure  software — 
honing  their  skills  to  think  like  an  attack¬ 
er — applying  dais  mindset  throughout  die 
SDLC.  The  book  describes  practices  to  get 
dais  ball  rolling,  such  as  attack  patterns  and 
assurance  cases.  Alternatively,  if  you  have 
access  to  experienced  security  analysts, 
adding  a  few  of  daem  to  your  development 
team  can  get  dais  jump-started. 

Two  of  the  key  project  management 
practices  are  1)  defining  and  deploying  a 
risk  management  framework  to  help 
inform  practice  selection  and  determine 
where  best  to  devote  scarce  resources  and 
2)  identifying  the  best  way  to  integrate  soft¬ 
ware  security  practices  into  the  organiza¬ 
tion’s  current  SDLC. 

Also  keep  in  mind  that  dais  process,  if 
done  properly,  will  take  time.  As  John 
Steven  stated: 

Don’t  demand  teams  to  begin  con¬ 
ducting  every  activity  on  day  one. 
Slowly  introduce  the  simplest  activ¬ 
ities  first,  tlaen  iterate  ...  [Have] 
patience.  It  will  take  at  least  three  to 
five  years  to  create  a  working,  evolv¬ 
ing  software  security  machine. 
Initial  organization-wide  successes 
can  be  shown  within  a  year.  Use 
that  time  to  obtain  more  buy-in  and 
a  bigger  budget.  [5] 

Clearly,  there  is  no  one-size-fits-all 
approach.  Project  managers  and  their 
teams  need  to  think  through  die  choices, 
define  dieir  tradeoff  and  decision  criteria, 
learn  as  diey  go,  and  understand  diat  diis 
effort  requires  continuous  refinement  and 
improvement. 

In  Closing 

Sound  software  security  engineering  prac¬ 
tices  should  be  incorporated  throughout 
the  entire  SDLC.  “Software  Security 
Engineering”  is  one  resource  diat  captures 
both  standard  and  emerging  software  secu¬ 
rity  practices  and  explains  why  they  are 
needed  to  develop  more  security-respon¬ 
sive  and  robust  systems.^ 


Software  Defense  Application 

The  book  “Software  Security  Engineering:  A  Guide  for  Project  Managers” — based 
primarily  around  the  DHS’  Build  Security  In  Web  site — is  a  defense  software 
industry  mainstay  for  selecting  the  right  systems  assurance  tools.  This  article  illu¬ 
minates  ways  to  use  the  book  in  planning  software  security  improvements,  from 
the  early  development  stages  through  deployment  and  operations.  As  well,  soft¬ 
ware  developed  using  the  suggested  practices  will  result  in  on-time  and  on-budget 
projects  that  are  more  predictably  secure. 
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Note 

1.  Material  from  this  article  has  been 
taken  from  the  preface  and  Chapter  8 
of  “Software  Security  Engineering:  A 
Guide  for  Project  Managers.”  It  is 
reproduced  with  permission  of  Pear¬ 
son  Education,  Inc.  For  additional 
information  about  die  book,  including 
a  full  table  of  contents,  please  refer  to 
<www.informit.com/ store/ product.as 
px?isbn=032150917X>  and  <www. 
sei.cmu.edu/library/ abstracts /books/ 
032150917X.cfm>.  As  well,  podcasts 
including  Julia  Allen,  Nancy  Mead,  and 
Gary  McGraw  are  a  nice  introduction 
to  the  book’s  content.  Find  the  CERT 
Podcast  series  at  <www.cert.org/pod 
cast/ #softsecurity>. 
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The  Department  of  Homeland  Security,  Office  of 
Cybersecurity  and  Communications,  is  seeking 
dynamic  individuals  to  fill  several  positions  in  the 
areas  of  software  assurance,  information  technology, 
network  engineering,  telecommunications,  electrical 
engineering,  program  management  and  analysis, 
budget  and  finance,  research  and  development,  and 
public  affairs.  These  positions  are  located  in  the 
Washington,  DC  metropolitan  are 


To  learn  more  about  DHS’  Office  of  Cybersecurity 
and  Communications  and  to  find  out  how  to  apply 
for  a  position,  please  visit  USAJOBS  at 
www.usaiobs,eov. 
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IBM  Rational  Software  Conference 
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Better  Software  Conference 
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Coming  Events:  Please  submit  coming  events  that 
are  of  interest  to  our  readers  at  least  90  days 
before  registration.  E-mail  announcements  to: 
<marek.steed.ctr@hill.af.mil>. 
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Building  security  into  software  is  harder  than  it  should  be.  This  article  explores  a  way  to  align  application  security  practices 
with  other  software  development  best  practices  in  order  to  make  building  security  in  easier  to  manage  and  more  cost  effective. 
In  particular,  this  article  looks  at  combining  continuous  integration  (Cl)  with  security  testing  and  secure  static  code  analysis. 


Application  development  and  security 
practices  are  often  at  odds.  Appli¬ 
cation  development  is  concerned  with 
creating  software  quickly  with  the  most 
features  possible  in  the  minimum  amount 
of  time.  Application  security  is  con¬ 
cerned  with  finding  and  removing  securi¬ 
ty  vulnerabilities  and  releasing  software 
when  critical  security  risks  have  been  mit¬ 
igated. 

Many  project  stakeholders  see  appli¬ 
cation  security  practices  as  an  increase  in 
scope  that  adversely  impacts  the  software 
delivery  schedule.  In  order  to  build 
secure  applications,  it  is  important  to 
align  application  development  and  securi¬ 
ty  practices.  Our  analysis  has  found  that 
one  of  the  best  ways  to  do  that  is  to  inte¬ 
grate  secure  code  analysis  and  security 
testing  into  CL  Cl  is  a  software  develop¬ 
ment  practice  where  members  of  a  team 
integrate  their  work  frequently,  verifying 
each  integration  by  an  automated 
build/test  process  to  detect  integration 
errors  as  quickly  as  possible  [1],  Using  Cl, 
the  time  and  effort  to  build  security  into 
the  development  process  can  be  mini¬ 
mized,  making  teams  more  likely  to 
include  security  practices  in  their  soft¬ 
ware  development  process  and  thereby 
reducing  the  risk  of  a  successful  attack. 

Immediate  Notification 

Cl  ensures  that  ongoing  changes  to  the 
source  code  do  not  break  the  intent  or 
design  of  the  software.  If  a  change  does 
break  the  software,  that  break  is  identi¬ 
fied  immediately  and  can  be  fixed  with  a 
minimal  cost  and  impact  to  the  project’s 
schedule. 

Cl  started  with  die  notion  that  each  Cl 
cycle  should  make  a  clean  build  from  an  up- 
to-date  checkout  from  the  source  code 
repository,  and  that  a  set  of  unit  tests 
should  be  run  against  the  clean  build  as  a 
regression  against  the  changes  in  the  code 
base.  If  the  build  and  unit  tests  pass,  then 
die  recent  checked-in  changes  did  not 
break  die  software.  If  die  build  or  unit 
tests  fail,  then  the  changes  broke  die  soft¬ 
ware,  and  the  Cl  server  immediately  noti¬ 
fies  the  team  that  die  software  is  broken. 


Secure  Development 

Cl  is  now  die  foundation  for  serving  many 
crucial  software  development  process 
tasks.  Originally  focused  on  compiling  and 
unit  testing,  Cl  practices  have  grown  and 
evolved  over  time.  They  now  include 
expanded  practices,  such  as  functional  test¬ 
ing  and  code  analysis  to  evaluate  the  health 
of  a  project.  By  integrating  security  testing 
and  secure  code  analysis,  Cl  can  be  further 
leveraged  to  include  secure  development 
practices  while  minimizing  die  amount  of 
extra  effort  required  to  get  die  benefits  of 
secure  development.  Since  it  is  tied  to  Cl, 
security  testing  and  secure  code  review 
begins  when  a  project  begins  and  runs  con¬ 
tinuously  throughout  project  development. 
Widi  Cl,  security  vulnerabilities  testing 
becomes  part  of  the  regression  test  bed, 
executed  automatically  widi  each  successive 
build  on  the  Cl  platform. 

Changing  Testing  Economics 

Technology  advances  have  changed  die 
economics  of  testing,  allowing  more 
aggressive  approaches  to  testing  dian  his¬ 
torically  possible.  Using  Cl  for  build,  test, 
and  analysis  automation  has  increased  die 
depth  and  breadth  of  tests  while  also  mak¬ 
ing  them  faster  and  less  expensive.  By  mak¬ 
ing  it  cheap  and  easy  to  perform  tests, 
teams  are  encouraged  to  test  more  and  test 
sooner  in  die  development  cycle,  reducing 
die  cost  of  fixing  bugs.  It  has  also  made  it 
easier  for  managers  and  non-technical 
stakeholders  to  understand  project 
progress  and  healdi. 

For  many  projects,  testing  has  gone 
from  a  process  that  slowed  deployment 
down  to  one  diat  provides  true  quality 
assurance,  in  turn  helping  stakeholders 
have  more  confidence  in  dieir  projects.  By 
reducing  die  cost  of  many  quality  control 
aspects  of  application  development,  teams 
have  been  able  to  use  diose  controls  more 
often  and  more  effectively  and  have  accel¬ 
erated  development  while  improving  quali¬ 
ty.  This  same  change  can  be  applied  to 
security  practices  integrated  into  CL  The 
reduced  cost  of  gathering  security  vulnera¬ 
bility  data  will  encourage  teams  to  collect 
die  data  more  often  and  sooner  in  dieir 


development  cycle,  reducing  the  cost  to  fix 
issues  such  as  cross-site  scripting  and  SQL 
injection. 

Building  Security  Testing 
Into  Cl 

In  order  to  integrate  static  code  analysis 
and  security  testing  into  Cl,  a  few  key 
pieces  of  software  are  needed.  Organiza¬ 
tions  should  select  a  specific  application  for 
each  of  the  software  categories  (as  shown 
in  Table  1),  bearing  in  mind  diat  some 
products  might  fit  into  more  dian  one  cat¬ 
egory.  For  example,  Microsoft’s  Team 
Foundation  Server  (TFS)  [2],  fits  into  the 
Cl  Server,  Source  Code  Repository,  and 
Issue  Tracking  categories. 

Choosing  the  Right  Tools 

It  is  possible  to  build  a  completely  open 
source  Cl  process  that  includes  static  code 
analysis  and  security  testing.  Secured  is 
one  example  of  a  Cl  product  diat  is  made 
of  all  open  source  tools  and  can  be  down¬ 
loaded  and  used  free  of  charge  [3].  There 
are  also  many  good  commercial  products 
that,  in  some  cases,  provide  more  value 
than  dieir  open  source  alternatives,  such  as 
the  Web  crawling  capability  of  AppScan 
and  Weblnspect. 

There  are  many  tools  to  choose  from, 
ranging  from  unsupported  to  company- 
supported  open  source  software  to  com¬ 
mercial  software  diat  is  developed  and 
maintained  completely  by  the  company 
that  created  it.  In  odier  words,  an  organiza¬ 
tion  can  purchase  support  contracts  to 
commercial  software — products  diat  are 
then  developed  and  maintained  completely 
by  the  company  that  created  diem.  There 
are  even  some  commercial  software  prod¬ 
ucts  diat  are  free  to  use  but  come  with 
some  restrictions,  such  as  a  limited  number 
of  users.  There  is  no  correct  or  incorrect 
tool  as  long  as  the  acquired  software  works 
together  and  can  meet  organizational 
objectives. 

Tool  Integration 

In  general,  the  Cl  server  will  be  the  inte¬ 
gration  hub  and  orchestrator  for  a  Cl 
process.  Cl  servers  come  widi  integration 
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application  programming  interfaces  (APIs) 
for  many  of  the  tools  an  organization  puts 
in  its  toolset  so  that  working  with  those 
tools  will  be  easy.  If  there  isn’t  an  API  for 
one  of  the  selected  tools,  Cl  servers  can  be 
extended  using  scripting  languages  and 
compiled  code  plug-ins.  This  flexibility 
means  that  an  organization  can  add  any 
tools  that  can  be  scripted  or  programmati¬ 
cally  controlled  into  their  Cl  process,  mak¬ 
ing  it  possible  to  add  security  practices  to 
an  existing  Cl  process  without  having  to 
reinvent  that  process.  For  example,  with 
Hudson,  in  order  to  use  PMD  [4]  or 
FindBugs  [5]  for  static  code  analysis,  all 
that  is  needed  is  creation  of  a  build  job  that 
uses  an  Ant  [6]  build  to  run  the  tool.  You 
then  point  the  tool’s  Hudson  [7]  plug-in  to 
the  XML  reports  created  during  the  Ant 
build.  The  plug-in  picks  up  the  reports  and 
parses  them  for  display  using  HTML  and 
generated  graphics. 

The  Cl  server  market  is  full  of  both 
open  source  and  commercial  products. 
Many  of  the  open  source  Cl  servers  have 
commercial  support  contracts  available. 
Because  of  the  mature  Cl  server  market, 
there  is  no  advantage  in  using  either  open 
source  or  commercial  products.  The  excep¬ 
tion  to  this  statement  is  when  an  organiza¬ 
tion  is  considering  development  ecosystem 
suites  like  Microsoft’s  TFS  and  Visual 
Studio  suite. 

Integrating  security  testing  tools 
requires  a  litde  more  work.  The  application 
under  test  needs  to  be  deployed  and  run¬ 
ning  because  security  testing  tools  work  by 
interacting  with  the  application,  analyzing 
the  requests  and  responses  from  the  point 
of  view  of  a  Web  browser.  This  means  that 
the  Cl  server  will  have  to  deploy  to  an 
application  server,  start  it,  and  then  kick  off 
the  security  testing  tool.  While  it  seems  like 
a  lot  of  work,  there  are  a  number  of  good 
examples  on  the  Internet  to  help  get  start¬ 
ed.  The  commercial  security  testing  tools 
can  be  configured  to  just  launch  and  crawl 
an  application. 

Creating  Multiple 
Complementary  Builds  to 
Support  Specific  Needs 

One  of  the  first  things  organizations  will 
notice  about  using  static  code  analysis  and 
automated  security  testing  tools  is  that 
build  times — the  time  it  takes  to  go 
through  a  Cl  process — will  increase  signif¬ 
icantly.  Because  of  this  increase,  it  is  com¬ 
mon  for  projects  to  use  multiple  Cl  jobs. 
The  different  jobs  are  set  to  run  on  differ¬ 
ent  intervals  and  for  different  reasons.  For 
instance,  most  teams  have  a  quick  job  that 
runs  within  10  minutes  of  a  check-in  and 


produces  a  result  within  10  minutes.  This 
quick  job  consists  of  a  clean  build  and  only 
executes  unit  tests.  This  quick  build  tells  the 
developers  that  the  new  code  works  and 
that  all  of  the  unit  tests  pass  (i.e.,  the  code 
hasn’t  introduced  defects  into  previously 
working  code).  Many  teams  will  also  use 
longer  running  tests  (a  couple  of  hours), 
compiling  the  project  and  running  die  unit 
tests,  while  also  executing  other  kinds  of 
tests  (e.g.,  database  tests  and  automated 
functional  tests).  These  tests  take  longer  to 
complete  and  have  a  longer  feedback  cycle. 
By  executing  multiple  jobs,  an  organization 
can  provide  the  team  with  feedback  as 
quickly  as  possible  for  a  given  type  of  feed¬ 
back.  Finally,  many  projects  have  jobs  run¬ 
ning  from  once  a  day  to  once  a  week  that 
perform  static  analysis  or  security  testing. 
This  allows  the  processes  to  run  at  their 
own  pace  without  slowing  down  other  test 
processes. 

The  selection  of  a  source  code  reposi¬ 
tory  is  generally  based  on  what  already 
exists  in  an  organization’s  environment. 
From  the  overall  goal  of  building  security 
into  applications,  the  choice  of  source 
repository  makes  little  difference — it  just 
needs  to  work  with  the  Cl  server. 

Utilizing  Both  Commercial 
and  Open  Source  Tools 

There  is  a  healthy  marketplace  for  issue 
tracking  applications  having  both  open 
source  and  commercial  products. 

Commercial  issue  tracking  software  has 
an  advantage  over  open  source  in  terms  of 


the  reporting  and  integration  options. 
Commercial  applications  tend  to  have  a 
better  and  more  customizable  reporting 
system  and  tend  to  integrate  more  with 
(usually  commercial)  software  that  might 
be  used  in  an  overall  development  process. 
That  said,  many  projects  and  organizations 
don’t  need  or  use  the  extra  capability  of 
commercial  issue  tracking  software.  For 
small  project  teams  or  small  companies, 
open  source  issue  tracking  software  works 
just  fine.  For  large  enterprises  with  multiple 
related  development  projects,  a  commercial 
issue  tracking  application  may  offer  needed 
features  that  can  justify  the  cost  of  acquir¬ 
ing  the  software. 

Open  source  unit  testing  tools  are  usu¬ 
ally  frameworks  that  provide  a  core  unit 
testing  capability.  These  tools  require  a 
developer  to  write  and  maintain  unit  tests. 
If  the  developer  follows  the  conventions  of 
the  framework,  running  unit  tests  is  very 
simple  and  easy  and  many  Cl  servers  can 
read  and  report  on  the  results.  The  com¬ 
mercial  products  in  the  space  build  on  top 
of  the  open  source  tools  by  adding  the 
capability  to  generate  unit  tests.  The  com¬ 
mercial  tools  will  scan  the  source  code  and 
determine  how  to  exercise  the  code  paths 
(in  die  source  code)  in  order  to  get  100  per¬ 
cent  test  coverage  and  possibly  add  nega¬ 
tive  unit  tests. 

We  have  worked  on  projects  that  have 
used  both  developer-written  unit  tests  and 
tool-generated  unit  tests.  When  dealing 
with  security  features,  it  is  important  to 
write  comprehensive  unit  tests  that  exercise 
both  the  positive  and  negative  paths 


Table  1:  Tools  for  Different  Software  Categories 


Software 

Category 

Description 

Open  Source 
Tools 

Commercial 

Tools 

Cl  Server 

Server  software  that  monitors  the 
source  code  repository  and  runs 
the  build  when  changes  to  the 
repository  are  detected. 

Hudson, 

CruiseControl 

TeamCity, 

Bamboo, 

TFS 

Source  Code 
Repository 

Software  that  keeps  source  code, 
maintaining  versions  of  the  source  files 
and  file  groups  (i.e.,  labels  and  tags). 

Concurrent 

Versions 

Systems, 

Subversion 

Polytron 

Version  Control 

System, 

Clearview, 

TFS 

Issue  Tracking 

Software  that  is  used  to  manage  software 
issues  and  report  their  status. 

Trac  and 

Sonar, 

Bugzilla 

Quality 

Center, 

TFS 

Unit  Testing 

Tools  or  frameworks  used  by  developers 
to  test  at  a  source  code  level. 

JUnit, 

NUnit 

JTest 

Functional  Testing 

Tools,  frameworks,  or  applications 
used  to  test  the  functionality  of  software. 

Selenium, 

Watir 

Quick  Test 

Professional, 

SilkTest 

Security  Testing 

Tools,  frameworks,  or  applications  used 
to  test  the  security  aspects  of  software 
(i.e.,  penetration  testing  tools). 

RatProxy, 

WebScarab 

AppScan, 

Weblnspect 

Static  Code 
Analysis 

Tools,  frameworks,  or  applications  used 
to  inspect  either  source  code  or  compiled 
files  for  known  issues. 

FindBugs, 

PMD, 

CheckStyle 

Fortify 

Source  Code 
Analyzer 
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Software  Defense  Application 

Application  security  is  a  priority  for  DoD  applications,  given  the  always  on,  global 
nature  of  the  DoD  mission.  At  die  same  time,  it  is  important  to  make  application 
security  work  within  the  development  practices  in  common  use  among  DoD  devel¬ 
opment  teams.  By  integrating  application  security  practices  with  Cl,  we  can  address 
both  the  security  needs  of  the  applications  as  well  as  the  efficiency  and  cost-effective 
requirements  of  the  development  teams. 


through  the  code.  Many  security  defects 
come  from  security  features  that  don’t  have 
a  proper  fail-safe  method  for  when  there  are 
program  or  data  processing  errors. 
Negative  testing — or  the  testing  for  failure 
paths  in  the  source  code — addresses  the 
correctness  of  failure  states  and  can  show 
that  a  specific  security  feature  can  fail- 
safely  when  something  unexpected  hap¬ 
pens.  If  there  is  a  large  legacy  code  base 
diat  doesn’t  have  unit  tests,  using  a  tool  to 
generate  unit  tests  is  a  good  way  to  add 
tests  quickly.  Keep  in  mind,  however,  that 
die  project  team  still  needs  to  review  all  of 
those  tests,  change  some,  remove  others, 
and  write  new  tests  covering  situations 
diat  the  tools  couldn’t. 

Security  Testing  Tools 

Security  testing  is  an  excellent  way  to  dis¬ 
cover  many  of  the  security  vulnerabilities 
in  an  application.  These  tools  are  run 
against  an  application,  usually  in  a  testing 
environment,  in  its  production  configura¬ 
tion.  One  goal  of  this  testing  is  to  deter¬ 
mine  if  the  application  has  defects,  mak¬ 
ing  it  vulnerable  to  outside  attack  while  in 
production;  another  is  to  see  if  the  appli¬ 
cation  will  fail  safely  when  attacked. 
Failing  safe  has  different  meanings  to  dif¬ 
ferent  applications,  with  the  basic  guide¬ 
line  that  an  application  should  not  give 
users  unauthorized  information  or  allow 
them  to  take  unauthorized  actions. 

In  order  to  automate  many  open 
source  security-testing  tools,  they  will 
need  to  be  used  in  conjunction  with  func¬ 
tional  test  tools.  For  example  Ratproxy  [8], 
a  popular  open  source  security-testing 
tool,  can’t  (unlike  popular  commercial 
security  testing  tools)  crawl  a  Web  applica¬ 
tion.  This  means  that  people  using 
Ratproxy  need  to  use  another  tool  to  crawl 
the  Web  application  while  Ratproxy  is 
running.  Another  alternative  is  to  have  the 
testers  use  Ratproxy  while  they  are  con¬ 
ducting  manual  functional  tests. 

Another  area  where  commercial  secu¬ 
rity  testing  tools  have  an  advantage  is  in 
reporting.  Commercial  security  testing 
tools,  like  AppScan  [9],  have  a  customiz¬ 
able  reporting  capability  that  gives  users 
numerous  ways  to  report  their  findings  (in 
order  to  conform  to  organizational  stan¬ 


dards  or  highlight  different  aspects  of  the 
findings  for  different  audiences).  The 
reporting  capability  also  does  a  good  job 
of  explaining  the  findings — that  is,  how 
diey  can  be  exploited  and  remediated.  In 
contrast,  Ratproxy  has  only  one  report 
format  that  provides  little  detailed  infor¬ 
mation  about  an  issue  beyond  its  name 
and  where  it  was  found.  An  analyst  using 
Ratproxy  has  to  figure  out  what  the  issue 
means  and  how  to  remediate  it.  Finding 
out  dais  information  isn’t  hard,  but  it  can 
be  time-consuming. 

Static  Code  Analysis  Tools 

Static  code  analysis  tools  examine  the  code 
base  for  many  problems  including  security 
and  code  style  issues,  potential  code 
defects,  and  race  conditions.  These  tools 
are  more  akin  to  automated  code  review 
than  to  unit  and  integration  tests.  The  dif¬ 
ference  between  commercial  and  static 
code  analysis  tools  mirror  die  differences 
found  in  security  testing  tools:  Commercial 
tools  have  better  reporting  capabilities  and 
provide  more  information  on  die  nature  of 
die  findings  and  suggested  remediation. 
Another  area  where  some  commercial 
tools  have  added  value  is  in  die  depth  of 
analysis.  Fortify  Software’s  Source  Code 
Analyzer  [10]  creates  an  entire  model  of 
die  application  under  analysis,  examining 
die  data  and  control  flow  of  die  software 
to  determine  if  diere  is  a  larger-context 
problem.  Most  open  source  static  code 
analysis  tools  only  look  for  problems  in  a 
local  context  (i.e.,  die  immediate  line  of 
code,  code  block,  or  file). 

Static  code  analysis  can  either  be  per¬ 
formed  on  die  source  code  of  an  applica¬ 
tion  or  on  the  compiled  binaries.  For  exam¬ 
ple,  FindBugs  runs  against  compiled  Java 
class  files.  It  can  find  bad  practices,  null 
pointer  dereferences,  static  use  of  non¬ 
thread  safe  code,  and  security  issues.  PMD 
runs  against  Java  source  files.  It  can  find 
dead  code,  performance  issues,  style  issues, 
and  potentially  dangerous  code  practices. 
While  diere  is  overlap  widi  FindBugs,  using 
both  is  not  considered  redundant. 

Data  Analysis  and  Evaluation 

Once  the  vulnerability  data  has  been  col¬ 
lected  from  both  security  testing  and  code 


analysis,  it  has  to  be  analyzed  and  evaluat¬ 
ed.  The  goal  of  this  step  is  to  decide  if  the 
findings  are  truly  a  problem  and  what  to 
do  about  it.  This  step  includes  determining 
the  priority  and  severity  of  the  security 
issues  and  putting  them  into  an  issue  track¬ 
ing  system.  In  order  for  application  securi¬ 
ty  practices  to  positively  affect  the  project, 
issues  uncovered  in  testing  and  analysis 
need  to  be  tracked  and  fixed.  By  integrat¬ 
ing  security  practices  into  Cl,  security 
issues  are  discovered  and  dealt  with  more 
quickly,  in  turn  preventing  many  security 
risks  from  entering  production  and  mini¬ 
mizing  die  possibility  of  exploitation. 

Building  application  security  practices 
into  a  project  can  be  done  with  minimum 
impact  to  a  project’s  budget,  schedule,  and 
resources.  Integrating  security  testing  and 
secure  code  analysis  into  Cl  is  die  first 
step  to  building  security  into  software. 
These  practices  help  build  security  aware¬ 
ness  by  showing  developers  how  and  why 
their  code  is  vulnerable.  They  give  testers 
the  tools  needed  to  find  many  security  vul¬ 
nerabilities,  and  project  managers  a  way  to 
demonstrate  die  results  of  security  prac¬ 
tices.  While  it  would  be  instructive  to  pro¬ 
vide  quantitative  analysis  of  the  benefits 
of  integration  Cl  and  security,  die  practice 
is  still  new  enough  that  no  major  studies 
have  been  conducted. 

Application  security  practices  are  hard 
for  many  teams  to  adopt  because  they 
don’t  have  the  time,  budget,  or  resources 
needed.  Cl  can  help  change  the  econom¬ 
ics  of  security  testing  and  analysis  by  giv¬ 
ing  project  teams  tools  that  can  be 
deployed  in  their  environment.  These 
solutions  can  enable  a  team  to  quickly  go 
from  not  considering  security  to  a  solid 
initial  step  in  finding  and  proactively  fixing 
security  vulnerabilities. ♦ 
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Making  Security  Measurable 

http:// measurablesecurity.mitre.org 

At  the  heart  of  this  issue’s  article  Systems  Assurance  as  a  Team 
Sport  are  several  MITRE-led  information  security  commu¬ 
nity  standardization  activities  and  initiatives — now  visit  the 
Web  site  which  houses  comprehensive  information  on  them 
all.  The  goal  of  this  collaboration  with  government,  indus¬ 
try,  and  academic  stakeholders  is  to  improve  the  measurabil¬ 
ity  of  security  through  enumerating  baseline  security  data, 
providing  standardized  languages  as  a  means  of  communi¬ 
cating  accurately,  and  encouraging  the  sharing  of  the  infor¬ 
mation  with  users  by  developing  repositories.  These  efforts 
are  helping  to  make  security  more  measurable  by  defining 
the  concepts  that  need  to  be  measured  and  providing  a  loca¬ 
tion  for  high-fidelity  communications  about  the  measure¬ 
ments. 

Engineering  for  System  Assurance 

www.acq.osd.mil/sse/docs/SA-Guidebook-vl-Qct20Q8.pdf 
After  reading  A  DoD-Oriented  Introduction  to  the  NDIA’s 
System  Assurance  Guidebook,  why  not  go  directly  to  the 
source?  This  Guidebook  provides  process  and  technology 
guidance  to  increase  the  level  of  systems  assurance.  It  is 
intended  primarily  to  aid  program  managers  and  systems 
engineers  who  are  seeking  guidance  on  how  to  incorporate 
assurance  measures  into  their  system  life  cycles.  The 
Guidebook  discusses  systems  assurance  by  focusing  on  the 
entire  system,  and  specifically  addressing  the  assurance  of 
security  properties  throughout  the  system  life  cycle.  It  also 
identifies  processes,  methods,  techniques,  activities,  and 
tools  for  systems  assurance,  and  focuses  on  the  electronic 
hardware,  firmware,  and  software  elements  that  make  up  the 
system. 

Forge.mil 

www.forge.mil 

In  their  article,  Michael  Atighetchi  and  Dr.  Joseph  Loyall 
state  their  belief  that  successful  survivability  assessment 
includes  community-based  collaboration  platforms.  They 
mention  Forge.mil,  a  Defense  Information  Systems  Agency- 
led  family  of  services  provided  to  support  the  DoD’s  tech¬ 
nology  development  community.  The  system  currently 
enables  the  collaborative  development  and  use  of  open 
source  and  DoD  community  source  software.  These  initial 
software  development  capabilities  are  growing  to  support 
the  full  system  life  cycle  and  allow  for  continuous  collabora¬ 
tion  among  all  stakeholders,  including  developers,  testers, 
certifiers,  operators,  and  users.  Forge. mil’s  goals  include 
enabling  and  promoting:  cross-program  sharing  of  software, 
system  components,  and  services;  early  and  continuous 
stakeholder  collaboration;  the  rapid  delivery  of  effective  and 
efficient  development  and  test  capabilities  for  DoD  technol¬ 
ogy  development  efforts;  and  the  protection  of  the  opera¬ 
tional  environment  from  potentially  harmful  systems  and 
services. 

Software  Assurance  (SwA) 

https://buildsecurityin.us-cert.gov/swa 

This  issue’s  focus  on  systems  assurance — and  the  article 
from  Julia  H.  Allen,  Dr.  Robert  J.  Ellison,  Dr.  Nancy  R. 
Mead,  Sean  Barnum,  and  Dr.  Gary  McGraw  outlining  the 


importance  of  the  DEIS’  Build  Security  In  (BSI)  Web  site — 
make  it  a  perfect  time  to  visit  this  BSI-sponsored  site,  specif¬ 
ically  focused  on  SwA.  Visitors  can  learn  more  about  what 
SwA  is,  why  it  is  critical,  how  it  is  advancing,  the  DHS’  SwA 
Program,  past  and  present  SwA  Forum  meetings,  and  the 
progress  of  specific  SwA  “working  groups.”  There  are  also 
links  to  several  of  their  published  resources,  past  and  future 
events,  as  well  as  to  Webinars,  Webcasts,  and  podcasts. 

Software  Testing  Boot  Camp  -  The 
Economics  ofTesting 

www.riceconsulting.com/public  pdf/STBC-WM.pdf 
In  Building  Security  In  Using  Continuous  Integration,  Thomas 
Stiehm  and  Gene  Gotimer  explore  the  economics  of  software 
testing,  stating  that  it  has  “gone  from  a  process  that  slowed 
deployment  down  to  one  that  provides  true  quality  assurance.” 
This  document  has  more  evidence  to  support  this  assertion, 
discussing  early  defect  detection  and  exploring  why  software 
defects  are  costly  to  find  and  fix.  As  part  of  a  four-day  “boot 
camp,”  it  explores  the  cost  of  software  defects,  where  defects 
originate,  why  a  “big  bang”  testing  phase  at  the  end  of  a  pro¬ 
ject  doesn’t  work,  the  relative  cost  of  defect  fixing,  as  well  as 
the  benefits  of  testing  early — and  throughout  a  project. 

Systems  Assurance  and  Cybersecurity: 
Giuidance  and  Tools 

www.acq.osd.mil/ sse/ pg/  guidance.html#sa 

Looking  for  a  “one-stop  shop”  for  pertinent  government  and 
DoD  documents  on  systems  assurance?  At  this  Systems  and 
Software  Engineering  Web  site — sponsored  by  the  Office  of 
the  Deputy  Under  Secretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics — visitors  can  access  the  most  perti¬ 
nent  government  publications  and  Web  sites  for  systems  assur¬ 
ance,  including  the  “Defense  Acquisition  Guidebook,”  the 
historical  “Acquisition  Systems  Protection  Program”  manual, 
Version  1.0  of  “Engineering  for  System  Assurance,”  and  the 
recently-released  “Acquisition  Security  Related  Policies  and 
Issuances  Tool.”  This  site  also  provides  resources  in  the  DoD 
focus  areas  of  Defense  Acquisition,  Systems  Engineering, 
Developmental  Test  and  Evaluation,  and  Modeling  and 
Simulation,  as  well  as  procedural  documents  from  the  Army, 
Navy,  Air  Force,  and  NASA. 

Maturity  Framework  for  Assuring 
Resiliency  Under  Stress 

https:/ /buildsecurityin.us-cert.gov/ daisv/bsi/ 10 1 6-BSI.html 
Don  O’Neill  expands  on  his  Sept. /Oct.  2009  CROSSTALK 
article  Meeting  the  Challenge  of  Assuring  Resiliency  Under  Stress, 
now  exploring  his  Maturity  Framework.  The  concept  is 
intended  to  drive  the  business  case  and  enterprise  commit¬ 
ment  towards  the  assurance  of  software  security,  business  con¬ 
tinuity,  system  survivability,  and  system  of  systems  resiliency. 
The  framework  serves  as  a  road  map  to  help  software  develop¬ 
ers  and  managers  in  understanding  the  software  security  deci¬ 
sion  process,  to  guide  the  selection  of  models  appropriate  for 
the  enterprise,  and  to  assist  in  their  instantiation  using  local 
factors  that  best  characterize  the  business  environment  and 
enterprise  culture  in  achieving  the  best  possible  outcome. 
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Coming  in  the  May/June  Issue 


Software  Human  Capital 

Understanding  of  the  economic  importance  of  people  goes  back  to  the  1 700s,  with  Adam  Smith’s  declaration  that  humans 
are  one  of  the  four  types  of  “capital.”  Software  managers  are  quickly  finding  that  success  comes  from  human  intelligence, 
innovation,  and  teamwork — and  that  failures  are  rooted  in  the  sociological,  rather  than  the  technological. 

This  edition  of  Crosstalk  documents  success  stories  and  explores  the  possibilities 
in  developing  the  skills,  talents,  knowledge,  and  abilities  needed  to  both  perform  at  a  high  level  and 

produce  innovative  products. 

Look  for  it  in  your  mailbox  early  May! 
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2009  Top  5  DoD 
Program  Awards 


Sponsored  by  Department  of  Defense  Systems  Engineering  Directorate  and 
National  Defense  Industrial  Association  Systems  Engineering  Division 

The  awards,  presented  to  both  government  and  industry,  recognize  significant 
systems  engineering  achievement  by  teams  of  industry  and  government  personnel. 

-  Winners  must  demonstrate  successful  implementation  of  systems  engineering 
best  practices  resulting  in  program  success  based  on  2009  performance. 

<'  Programs  are  considered  for  this  award  at  any  point  in  the  programmatic 
life  cycle. 

o  Successful  applicants  should  have  passed  a  sufficient  number  of  internal 
milestones  to  demonstrate  the  impact  of  systems  engineering  practices. 

Nomination  packages  due  July  1.  2010.  Programs  will  be  notified  by  September  1 
of  their  selection.  Awards  will  be  presented  at  the  annual  NDLA  Systems 
Engineering  Conference,  San  Diego,  CA,  October  25-28,  2010. 


VISIT  THE  NDIA  WEBSITE  TO  DOWNLOAD  SUBMISSION  INSTRUCTIONS 
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Letter  to  the  Editor 


Dear  CROSSTALK  Editor,  •  David  P.  Quinn’s  Resistance  as  a  Learning  Opportunity  discussed 

I  have  found  CROSSTALK  to  be  an  exceptional  resource.  In  gen-  why  and  how  people  resist  process  improvement  (PI),  and 
eral,  CROSSTALK  is  a  vast  repository  of  knowledge  for  those  in  effectively  showed  how  leaders  can  deal  with  resistance.  It  is 

defense  software  engineering.  Virtually  every  software  topic  has  its  often  difficult  for  someone  who  is  passionate  about  PI — and 

own  theme  issue.  One  of  our  software  engineers  asked  me  what  I  whose  full-time  job  it  is  to  help  implement  it — to  understand 

knew  about  Agile  Software  Development.  I  immediately  directed  and  deal  with  those  who  are  not.  Quinn  provided  solid,  practi- 
him  to  your  April  2007  issue,  diemed  Agile  Develop?nent,  which  was  cal  suggestions  for  doing  so.  Just  like  a  salesperson  making  a 

easy  to  access  on  your  Web  site  <www.stsc.hill.af.mil/ crosstalk/  sale,  PI  folks  need  to  “sell”  PI  with  what’s  in  it  for  the 

2007/04/>.  “resisters.”  It’s  a  fine  article  that  helps  the  PI  movement  go  for- 

Recent  editions  have  also  been  both  useful  and  enlightening.  I  ward, 
really  enjoyed  CROSSTALK’S  November/December  2009  issue,  •  Kudos  to  Gary  Petersen  for  his  BACKTALK  article,  Raiders  of 
focused  on  21st  Century  Defense:  the  Lost  Art.  Long  ago,  I  learned  the  difference  between  “effi- 

•  PK1:  The  DoD’s  Critical  Supporting  Infrastructure  for  Information  cient”  and  “effective.”  Something  that  is  fast  and  cheap  may  be 

Assurance  (LA)  by  Susan  Chandler  and  Jerrod  Loyless  was  a  efficient,  but  not  effective.  I  read  management  book  after  man- 

great  “101”-type  article  on  Public  Key  Infrastructure  (PKI)  and  agement  book  that  tried  to  teach  people  die  old  ways  of  com- 

IA.  It  was  the  first  time  I  have  really  understood  die  mechanics  munication  pointed  out  in  Petersen’s  article.  I  don’t  know  if  we 

of  both,  as  well  as  how  the  PKI  interfaces  with  my  Common  can  ever  get  the  tootiipaste  back  in  die  tube,  or  the  genie  back 

Access  Card.  I  now  appreciate  IA  a  whole  lot  more,  and  what  in  the  bottie,  but  thank  you  very  much,  Gary,  for  pointing  out 

goes  into  making  it  work.  die  wrong  direction  we  are  going  with  communication  and 

•  The  link  to  the  DoD  IA  Certification  and  Accreditation  offering  good  suggestions  for  getting  society  back  on  course. 
Process  page  (see  <www.stsc.hill.af.mil/crosstalk/2009/ll/  Thank  you,  CROSSTALK,  for  your  diligence,  dedication,  and 
09 1 1  WebSites.html>)  is  handy  to  have  around  when  IA  issues  great  articles! 

come  up.  Crosstalk’s  Web  Sites  section  is  an  extremely  valu¬ 
able  and  relevant  resource  for  busy  managers  who  don’t  have  — A1  Kaniss 

the  time  to  ferret  out  “nuggets”  like  this.  Naval  Air  Systems  Command 

I  also  liked  the  Process  Replication-themed  July/ August  2009  issue:  alan.kaniss@navy.mil 
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The  Software  Maintenance  Group  at  Hill  Air  Force  Base  is  recruiting  civilian  positions 
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tuition  assistance  and  time  off  for  fitness  activities.  Become  part  of  the  best  and  brightest! 


Hill  Air  Force  Base  is  located  close  to  the  Wasatch  and  Uinta 
mountains  with  many  recreational  opportunities  available. 
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My  Own  Kind  of  UML: 
Innovative  Technology  Transfer 
With  the  Universal  Motion  Language 


I’ve  been  thinking  a  lot  about  why  it  is  so  hard  to  get  soft¬ 
ware  right,  and  I  think  I  may  have  hit  on  something. 

I  have  noticed  when  visiting  with  relatives  who  live  in  the 
country  that  they  are  mechanically  astute.  They  can  fix  or 
jury-rig  almost  anything.  They  work  on  problems  at  least  as 
complicated  as,  say,  running  an  automated  payroll  system  for 
hourly  employees.  Ha vtyou  ever  tried  to  replace  the  boot  on 
a  compensating  velocity  gear  on  a  tractor,  or  unsnarl  an  old 
fishing  line  reel  and  not  lose  that  eight-pound  bass?  See  what 
I  mean! 

What  is  of  particular  interest  to  me  is  their  multi-channel 
knowledge  transfer  methodology.  When  describing  a  tech¬ 
nique  or  process,  conversations  are  punctuated  and  animated 
with  hand  motions  and  body  postures.  I  get  tired  just  watch¬ 
ing  one  explain  how  to  tighten  a  strand  of  barbed  wire  with 
nothing  but  a  broomstick  and  some  seagrass  string,  or  how 
to  pluck  a  chicken  for  supper  on  the  kitchen  table  when  it  is 
storming  outside. 

You  can  look  all  around  and  see  different  groups  with 
their  own  lexicon  of  hand  and  body  motions:  baseball  coach¬ 
es  instructing  a  runner  to  steal,  steelworkers  guiding  crane 
operators  as  they  put  I-beams  into  place,  or  a  driver  express¬ 
ing  disdain — with  merely  one  finger — when  another  driver 
cuts  them  off. 

Software  developers  are  no  less  creative  and  resourceful, 
but  are  clearly  missing  the  hand  motions  and  body  postures. 
I  recommend  computer  science  centers  of  excellence  imme¬ 
diately  pair  up  with  psychologists  in  academia  and  begin 
developing  these  visual  clues  forthwith. 

As  a  departmental  process  expert,  it  is  my  job  to  intro¬ 
duce  and  explain  the  latest  processes  and  forms  required  for 
all  projects.  In  my  opinion,  visuals  are  needed. 

I  have  worked  up  a  few  on  a  trial  basis,  such  as  inserting 
a  new  item  in  the  middle  of  a  doubly  linked  list.  I  find  the 
hand  motions  needed  to  help  explain  how  to  create  a  new 
relational  table  to  be  much  less  complicated  than  the  doubly 
linked  list — though  initial  trials  with  my  colleagues  on  the  job 
have  so  far  proved  unproductive. 

I  have  also  attempted  the  utilization  of  several  hand  signs, 
such  as  illuminating  the  walk-through  process  using  two  fin¬ 
gers  walking  across  the  desk.  Some  of  the  trainees  respond¬ 
ed  with  their  own  lower  energy-state  hand  sign  using  less 
motion  ...  and  fewer  fingers.  Hand  and  body  motions  are 
often  more  efficient  (requiring  less  mental  effort)  than  words 
in  expressing  concrete  ideas  and  procedures.  It  is  easier  to 
describe  a  spiral  staircase  with  your  hands  than  it  is  with 
words. 

In  my  humble  opinion,  these  less  than  enthusiastic  reac¬ 
tions  are  a  case  of  new  technology  being  rejected  by  sea¬ 
soned  veterans  who  fail  to  see  the  value  in  something  they 
didn’t  invent  themselves.  It  is,  as  they  say,  “not  the  way  we  do 
things  around  here.” 

I  wanted  to  call  this  new  technology  UML,  Universal 
Motion  Language,  but  I  am  told  that  acronym  has  already 
been  taken  by  some  upstart  language  those  smarty  college 


new-hires  keep  wanting  us  to  use1.  I  also  toyed  with  calling  it 
Associative  Symbolic  Signing,  but  my  wife  nixed  that  name. 
She  suggested  Symbolic  Transfer  Using  Polite  Indicative 
Directions. 

The  need  for  this  new  technology  is  accelerating  faster 
than  Moore’s  Law2  as  new  ideas  for  improving  software 
development  productivity  are  popping  up,  I  suspect,  at 
roughly  two  new  ideas  every  18  months.  Concomitant  with 
the  new  ideas  are  their  techniques,  processes,  models,  books, 
and  conferences,  thus  driving  up  the  need  for  better  knowl¬ 
edge  transfer  techniques  exponentially. 

We  are  almost  to  the  point  where  we  need  both  an  XML 
open  gesture  tag  and  close  gesture  tag  to  identify  the  ever¬ 
growing  list  of  standard  gestures  and  distinguish  them  from 
other  more  prosaic  hand  motions  and  postures,  such  as 
combing  one’s  hair,  scratching  one’s  posterior,  or  testing  the 
pH  of  one’s  azalea  bed. 

Adapting  this  technology  for  supply  chain  automation 
activities  should  be  a  great  place  to  start  since  the  hand  sig¬ 
nals  for  driving  a  truck,  pulling  inventory,  and  shelf  restock¬ 
ing  are  fairly  intuitive,  while  request-for-price  and  backorder 
transactions  would  be  more  problematic. 

But  if  we  make  this  technology  “freeware”  and  also  give 
away  rather  than  sell  the  documentation,  then  the  open 
source  and  freeware  communities  can  make  short  work  of 
those  type  problems.  After  all,  no  problem  can  withstand 
10,000  hands. 

— Carl  Wayne  Hardeman 

cwhardeman@yahoo.  com 

Notes 

1.  They  also  suggested  adopting  a  technology  they  call 
PowerPoint.  We  told  them  that  is  not  the  way  we  do 
things  around  here. 

2.  Moore’s  Law,  which  dates  back  to  1965,  states  that  the 
number  of  transistors  on  a  chip  will  double  every  two 
years.  See  <http://en. wikipedia. org/wiki/Moore’s_law> 
to  learn  more. 


Can  You  BACKTALK? 

Here  is  your  chance  to  make  your  point  without  your  boss 
censoring  your  writing.  In  addition  to  accepting  articles  that 
relate  to  software  engineering  for  publication  in  CROSSTALK, 
we  also  accept  articles  for  the  BACKTALK  column.  These  arti¬ 
cles  should  provide  a  concise,  clever,  humorous,  and  insight¬ 
ful  perspective  on  the  software  engineering  profession  or 
industry  or  a  portion  of  it.  Your  BACKTALK  article  should  be 
entertaining  and  clever  or  original  in  concept,  design,  or  deliv¬ 
ery,  and  should  not  exceed  750  words. 

For  more  information  on  how  to  submit  your  BACKTALK 
article,  go  to  <www.stsc.hill.af.mil>. 
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Build  Security  to  Moni« 

What  Is  Build  sccwtihr 


Software  Assurance 


Software 
is  essential 
to  enabling 
the  nation’s 

critical  infrastructure. 
To  ensure  the  integrity  of  that 
infrastructure,  the  software  that  controls 
and  operates  it  must  be  secure  and  resilient. 


Software  Assurance  Community  Resources  and  Information  Clearinghouse 
provides  collaboratively  developed  resources.  Learn  more  about  relevant 
programs  and  how  you  can  become  involved. 

https://buildsecurityin.us-cert.gov/swa/ 

Security  must  be  ‘  built-in”  and  supported  throughout  the  lifecycle. 

Visit  https://buildsecurityin.us-cert.gov  to  learn  more  about  the  practices  for 
developing  and  delivering  software  to  provide  the  requisite  assurance. 

Sign  up  to  become  a  free  subscriber  and  receive  notices  of  updates. 


The  Department  of  Homeland  Security  provides  the  public-private 
collaboration  framework  for  shifting  the  paradigm  to  software  assurance. 
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